In the software business we’ve settled on the analogy of ‘construction’ to describe most of what we do. While this is a lot better than a sports or war analogy, it doesn’t describe our work very well. In construction, planning is large and up front. You get all the permits and know exactly what you’ll build before you start. And while some things change during construction, most proceed in a linear fashion from start to finish. Then, upon completion, a different and much smaller team can handle the occasional maintenance requirements spaced out over the course of many years. Not exactly how any software project I’ve worked on could be described.

My previous career was as a musician, and I see a lot development teams acting a lot like the bands I used to work in. They have:

  1. A goal with fuzzy requirements that can be accomplished many different ways.
  2. Highly skilled members who often disagree. Loudly.
  3. A Requirement that the creators and the users approve of the end result. (The frontman will burn the tapes if they don’t like it.)
  4. Tight timelines.
  5. The same skill set is required for ongoing maintenance (touring).

Add in the fact that professional musicians are at least as difficult to corral as developers and you’ve got something a lot closer to your typical product development and release.

More importantly, the band analogy is a much closer match to the software development lifecycle than construction. It’s well understand in music that the writing process rarely proceeds linearly. It nearly always comes in fits and starts. Ideas are thrown out, or constantly reworked. Sometimes a song is nearly finished when major portions are rewritten when it just doesn’t “sound right.” And if you treat it like a ‘one piece at a time’ construction job the band will revolt. They have uniqueness that can either be embraced for the benefit of the project or snuffed out entirely.

Take your average development team and ask yourself if they’d do better at a strict 9-5 construction job with extremely detailed requirements and a manager constantly demanding they work faster, or if they’d do better if you gave them a fuzzy requirement like ‘make something great’, the best tools money can buy, and a week of uninterrupted time. I know which one I’d pick.