Posts Tagged legacy code
Looking to see when the next major release of the Thunderbird email client was planned, I came across a post by someone who’s involved in the Mozilla and Thunderbird development processes, at a place called dmose’s blog.
In the section titled Development Process: Increasing Agility, dmose says:
In recent years, Mozilla in general (but most especially Firefox) has moved towards a more agile development process.
Milestones have become shorter and more frequent in order to alleviate the pain felt when a feature misses a specific milestone, but also to apply pressure that keeps the code from drifting away from a shippable state. To the extent that it was done; this worked fairly well in the Firefox 3 cycle and is something that we should strive for in ongoing Thunderbird work.
Notice the language: moved towards… To the extent that… worked fairly well… something that we should strive for. It’s not stated in absolutes, because legacy code has an inertia to it that defies the simple, cohesive solutions one would apply to new code.
Specifically, 8 week cycles feel like a good starting point (though we’ve done slightly longer cycles for 3.0a1 and 3.0a2). Generally speaking, I think we also win by shipping to end users (i.e. non-alpha and non-beta milestones) relatively frequently (yearly? or even somewhat more frequently than that?) as well for exactly the same reasons.
Eight-week cycles? Yes — again, we’re not talking about starting over, so getting where we want to be means starting where we are. I bet the Mozilla team will find it to be a lot easier to eventually move toward seven- and six-week cycles than it was to get going with the notion of the shorter cycles in the first place. Trying to jump directly to two-week cycles would probably have been too drastic of a process change and led to a bad experience.
Dmose goes on:
Quite a bit more automated testing (of both regression and unit varieties) was integrated into the development process during the Gecko 1.9 and Firefox 3 cycle to great effect. The Firefox 3 nightly builds were usable as dogfood for almost the entire year before Firefox 3 shipped, which is an order of magnitude better than Firefox 2 nightlies were, and I believe this was a direct result of all the added tests. We should very much attempt to move Thunderbird in a similar direction.
It is painful to get a large existing codebase under test. But the benefits start to grow. They have for us too.
It’s Not Just Us
We too want our codebase to be more flexible and for it not to be so painful to add features and make changes. We too are working through the pain to try to get there. I guess it’s just encouraging somehow to know that a company that produces a world-class product like the Mozilla browser has this pain too, and is also working to change. Keep on, Mozilla guys!