Incremental Is Still Waterfall

Gojko Adzic posted yesterday about the waterfall trap for agile projects. In his post he makes the point that iterative development is not equivalent to incrememtal development.

Iterative implies that with each iteration the entire application will be the result. Each successive iteration will contain a greater level of detail than the iteration before it. And no iteration guarantees a “complete” or “finished” product.

In contrast, incremental development implies that each development cycle will yield only a portion of the total application. But what is produced is a more or less finished product.

This is where I do my bit about how frameworks are not right for every project.

Developers and managers tend to put their faith in a framework because they believe that the framework is a faster and/or cheaper way to obtain a certain set of functionality. That is to say that they feel that the framework is either a more “complete” solution than they could obtain by starting from scratch although it won’t necessarily save them any time, or they feel that the framework provides them with “enough functionality” to build what they need to build, and it will save them time.

Over time, a shop develops a body of expertise using a certain set of tools, or in this case, frameworks. And from then on they typically try to solve every problem with that same set of tools. A team becomes “a java shop”, or “cold fusion experts” or “ruby gurus”, etc.

An unspoken expectation from developers and managers is that the API for a framework will remain stable. They don’t want to have to go back and rewrite portions of their application because the framework changed.

This unspoken assumption is one of the things that makes frameworks a pain for some projects. This expectation of completeness means that frameworks are expected to be developed incrementally. It is expected that whatever is available is complete. And this means that frameworks are expected to be built in a non-agile way.

What’s important to remember here is that for each job you must use the right tool. Agile is new(er than waterfall). But that doesn’t mean that every other methodology is bad, or in some way inferior. Agile is great for some projects. Typically smaller projects are more appropriate for the agile methodology. But other projects are not right for (exclusively) agile methods. Larger projects really do benefit from things like frameworks when used appropriately.

A lot of managers I think would say they use agile methods. They would promote them and advocate for them as a way of saying “I get it! Waterfall is bad. Agile is cool. Let’s be cool!” But it’s important to realize that while agile is good, so are other methodologies.

It’s important to not confuse terminology to make something seem like something else in an effort to be cool. It’s also important to resist drinking the cool-aid. If you’re doing something, and it’s working for you, experiment and explore alternatives. But ultimately, be honest with yourself and your team about what works best for you. And when you decide to fix something, just be sure to use the right tool.