Zentrope

Thoughts on Iterative Development

Developers seem to repeat to each other in an echo-chamber kind-of-way various methodologies and memes in what after enough repetition feels like an empty cargo-cult faith.

Because I’m not immune, I like to revisit basic ideas.

Whenever I feel that there’s a lack of clarity (maybe even just on my part) about what a project adds up to, the response from others is that we use iteration to find out what it adds up to. It’s a conversation ender, it seems, in which any lateral approach is asserted to be nothing more than “waterfall”.

So, some thoughts:

• Business projects (for products) are waterfall: you plan, design, develop, market, deliver, all in the context of a strategic, business goal and according to a time schedule.

• Software projects are iterative: explore, invent, revise, learn-as-you-go: mini-waterfalls over and over.

• Iteration is a tactical technique for achieving a strategic goal.

• A strategic goal is not a vision statement, or an identification of a problem space.

• A strategic goal is a reasonably solid idea of what a release (even for a website) looks like and what it means for customers and the business.

• If there’s no strategic goal, iteration leads to muddle.

• Muddle is not a successful business strategy.

• Muddle is not a product.

Even the most stereotypically heads-down software engineers need to know the strategic goal. Repeat it to them over and over. It’s hard for them to remember when they’re mired in the day-to-day, iterative, tactical development but it’s absolutely necessary, because it’s the only way for them to make good choices, make sure they’re solving actual problems and minimize technical debt.

I think the relationship between the goal and the iterations meant to achieve it is often lost in the literature.

For instance, “maintaining” an existing product doesn’t really require a strategic goal and all the talk about formulaic iterative development and agile makes a lot more sense in that context.

Coming up with something new is a different case all together. Even if the strategic goals shift as the business changes (say, in a start up situation), those goals should be clear to everyone working on a project. (E.g., “DropBox: We’re a folder that syncs. That’s it. That’s what we do. If what you’re working on doesn’t contribute to solving the problems of being a folder that syncs, then don’t work on it.”)

Writing apps for specific end-customers who keep changing their minds (the use case for iterative development with lots of feedback, etc) can also lead to muddle. A nice strong contract with defined deliverables is good no matter what, even for fickle customers, and even given that it’s not so easy with software to determine if a deliverable is delivered.

The goal is to define a strategic goal and keep it in mind, no matter how difficult that is to do. It won’t guarantee business success, but the business failure won’t be because the software doesn’t work.