Binge and Purge

methodology

Sun Mar 23 14:01:00 -0700 2008

There’s a cycle to building software. First, you furiously write a bunch of code to get something working. It’s complicated, a bit messy, a bit unfocused - but you manage to get it to work, just barely, and then you can start using it. Being used by one or more real users (even if that’s just you, or you and a few others in your workgroup) then provides focus as to which features and functions are the most central.

Now the second half of the cycle begins: you start to trim it down, simplifying the code and data, trying to get the same functionality for the users with less code, fewer modules, less data complexity. At the end of this you come to a Zen-like state with your code, a minimalistic approach where you can subtract no more. From here, you now have a solid base to go back into the first cycle again, and start growing out your feature set.

Watch any good open source project to see this binge-and-purge cycle in action. Rails experienced this furious expansion of features in its early days, culminating around 1.2. Rails 2 was all about trimming down - doing more with less, focusing on core features that provide the most bang for the buck, moving everything else into external add-ons. Another one: Mozilla. After the open sourcing of Netscape, the codebase became a chaotic mess of building sprawling infrastructure components (Gecko, XUL, SpiderMonkey…). Once these had been built out, Phoenix Firebird Firefox showed up to trim, trim, trim down to a feature set that represented the core of what people really wanted out of a browser.

There’s an apparent paradox here. If you don’t let yourself write bad, messy, overly complex code you’ll never make anything really cool or revolutionary. But bad code is unmaintainable over the long term. So if you don’t take the time to factor down your bad, messy, overly complex code you’ll never have a solid base to build the next set of killer features upon.

Which stage is your project in right now? And if you’re on a team, do all the team members agree which stage the project is in?