Actually sorry, I don't really know of any management secrets, or secrets among management, and am I managing at all?

So: NZ/Lloyd, the discussion continues.

I didn't participate in the discussion during the iteration meeting largely because I couldn't hear what the hell people were saying.  Certainly such subtleties as intonations and intention were lost; I could barely make out the words half the time.  Except when Rob got pissed, because he was right next to his mic.  I heard that pretty well.

My interpretation of what David was asking was a larger question: when will TOPP be less reactive?  Lloyd is not a reactive project; it doesn't serve any external demand or need.  As long as we are reacting to these external demands, Lloyd or any project like Lloyd (of which there could be many) won't get any priority.  If, as Whit says, we're always working on Priority 1, then it'll just never happen.  My interpretation of "always working on priority 1" is that of course we can prioritize long-term goals, and that will come (though it still won't come if we're purely reactive).  A valid counterpoint is that to have a rich and diverse set of developments sometimes you have to work on things that aren't the primary focus at the moment -- that a kind of fuzz in priorities allows people to work on what they'll be productive on, or what excites them at that moment, or what they suspect but cannot confirm will be a useful line of development.  Or just that we won't lose all our individual momentum in the context switches.

(As an aside here: TOPP is much less reactive than many places; certainly less reactive than my last job.  Just so we keep some perspective.)

Anyway, when will TOPP be less reactive?  The response was: we don't know.  That's entirely valid of course.  The follow up should then be: how can TOPP become less reactive?  Maybe there was attempt to bring the discussion there; I was thoroughly lost at that point.  The discussion definitely didn't go there.  And probably an iteration meeting is not the forum for that discussion, though certainly that discussion needs to happen.

How Can TOPP Become Less Reactive?

So, here's my thoughts on this:

We become less reactive when we become more successful.  When we have something solid and functional which anticipates people's needs, or which at least doesn't hinder people from advancing in whatever way they want, even if we don't build in every specific pattern.  Also we can become less reactive when we have concrete success like Lots Of Users, or International Acclaim, or The Successful Outcome Of openplans.org-users' Projects.  Success builds trust.  We need to exceed expectations, at which point we'll be free to do determine our own path more.

Even then, determining our own path is not an end in itself.  We need to want to determine our own path.  We need to have strong opinions about our goals and means so that we have something to work towards without external demands.  I don't think we're at that place either.  I don't think, collectively, we are in tune with our users and the larger goals enough to be self-guiding in a productive and thoughtful way.  So we need to work towards that too.

Sometimes it's phrased as "we should be reacting to our users' needs, not just our funder's desires".  I don't personally want that either.  Listening to what users ask for isn't a great strategy in my mind.  Certainly some users come to the project with the experience and vision to ask for really great stuff: things that are both feasible and powerful, useful functionality that doesn't impose too much complexity.  Some users are like this.  But simply following requirements that are handed down is not healthy or productive, in my opinion.  Sometimes it takes discussion: kind of what the developer/customer negotiation and discussion is described as in agile methodologies.  But sometimes you have to actually make things, and see if they work.  I would love to see an environment where individuals here just make things from time to time, based on a guess or a hope about what might work.  We're not there either; including that we aren't there technically, we aren't ready as an organization to support spikes like that where the spikes actually get deployed.  Part of my underlying motivation of the decoupled architecture is exactly that -- how can we safely go live with experiments?  It's a tricky question.  On the larger web it actually works pretty well, though even there it's not perfect.

What can we actually do, right now, to become less reactive?  I don't have a good answer.  We need to kick more ass, I guess.  I personally need to get more of my projects to completion, where "completion" means that they matter.  I don't think the answer is the same for every area of the code base or organization.  I think it's worth some conscious thought on all our parts.

What About Lloyd?

So, where does this put Lloyd?  Well, I have some concrete thoughts about that too.  Getting back to the comfortable area of technical suggestions, and away from strategy, here's my current opinion on how Lloyd should procede:

Everything should be focused on the last steps first.  That is, Lloyd has a bunch of bugs, missing features, etc.  Whatever, those are details, they are all things we could just fix given some time.  I'm not strictly a Hard Parts First developer, but here it makes sense to me; at least given the codebase's present state (which is fairly functional).  In this case, Hard Parts First(or Now) seems right: make sure the migration is as perfect as the codebase allows, and that it handles the load we need it to handle (and more).  I want to avoid a race situation between Lloyd and Zope/OpenCore, particularly because we might not be able to firmly focus on Lloyd for a while, and the race isn't really fair then.  It's also hard, because if we get Lloyd to 99%, but that 99% doesn't include a completely solid migration and load testing, we're really not at 99%, we're just fooling ourselves.

Another benefit here is that load testing fits in our current priorities fairly well; maybe not this iteration priorities, but probably it could go in the next iteration.  It applies equally to both code bases.  Luke did a little work on it before we deployed Deliverance, but it was just a point in time and we don't have any ongoing process.  Plus our site can be depressingly slow, and understanding how and when that happens is important, and gives us the basic tools to fix it (or at least improve it), applicable to any code base.  I will continue to raise the specter of a spam attack, where we get thousands of page writes a day.  We're not optimized for that, and it could totally kick our ass.

From there, getting feature parity between Zope and Lloyd seems more feasible, at least to me.  And there isn't any desperate rush to get that parity -- we can do it on a more relaxed schedule without the danger of Lloyd lingering for a painful eternity.  I've had rewrites or large releases linger for a painfully long amount of time in the past, and I want to avoid that here.