Thursday, August 6, 2009

Rewriting Systems and Waterfall: A Common Theme?

If batch size is the number of lines of code being delivered to production, completely rewriting systems and waterfall have one thing in common: Big Batch Sizes.

There are good reasons to rewrite your software. Like it being dependent on technology that is no longer supported [1]. The belief that the code is a mess in not a good one [2].

When you make the decision to rewrite a system, your customer will not get any benefits until your brand new system catches up to the features already available in the old one. In other words, the batch size is as large as the current system. Perhaps a little bit smaller, but not much. Similarly, in a pure waterfall project, your customers will not get the benefits until you finish it.

To reduce the batch size you could slowly rewrite small parts of the code until it gets to the desired state (Refactoring), or migrate the code feature by feature (Vertical Slice Migration). Let's call these approaches Small Releases.

Vertical Slice Migration and Refactoring aren't always attainable. Vertical Slice Migration might not be possible if the system you are replacing is tightly integrated or doesn't have an easy way to make an external call for example. You shouldn't use Refactoring if the desired state is not a natural progression from the current one. That's normally the case when you are moving platforms or languages (i.e. COBOL to Java).

Reducing the batch size doesn't reduce cost, it allows your customers to give you feedback and realize the benefits of your efforts early. Each release you make to production has test, migration and deployment costs. Likewise, the waterfall method can also be cheaper than agile if you can fix requirements upfront (From my experience this is unrealistic in most cases). If there's no need for early feedback, doing multiple releases only makes the project more expensive.

As for the risk of the change, you could argue that Small Releases incur greater risk. After all, you are making multiple changes and that increases your probability of error. I think the opposite is true. By making small changes you are in better position to evaluate the risks and take the right approaches to mitigate them. It is easier to manage an incremental upgrade than
it is a full system deployment. This is also the case in a waterfall project where by doing a big bang release, the risk is concentrated in one single event: The Release.

In summary, a big batch is cheap to produce, but the consequences if it is bad can be severe.

[1] http://www.nytimes.com/2002/05/12/us/for-parts-nasa-boldly-goes-on-ebay.html
[2] http://www.joelonsoftware.com/articles/fog0000000069.html

ShareThis