Friday, July 2, 2010

When should software be rewritten

Over the last 14 years of my professional software development career, I have often heard developers complain about their existing code-base (including me). These complaints are generally along the same themes; how it has become difficult to maintain; that the code has become a big ball of mud; that changing code causes ripple effects; that no-one likes to touch module X because its so brittle; it takes new developers a long time to get up to speed with the code etc etc.

Normally the team consensus is that the product should be rewritten from the ground up. The idea is that this will sort out all of the design issues that are in the current version, it'll be more maintainable & more stable.

So the team embarks on this quest all the while management still wants new features and bug fixes to the existing version. This causes the original code-base to become a moving target causing the rewrite to take longer. This also ties up resources that could be working on new features, moving the product forward and adding value to the business.

In my experience the only time to rewrite a code-base is when moving to a new platform or technology. For example moving from Winforms to WPF. A rewrite is normally a lengthy and costly affair which rarely ends up with the clean design that was sought. New bugs are introduced which aren't covered by existing regression tests.

Rather than rewriting the entire application, the strategy I would recommend is to refactor it.

To get the most benefit from refactoring a code base, you'll need to increase testability. This will involve moving to a more loosely coupled design. I've chosen to use Behaviour Driven Design (BDD) which is an extension of Test Driven Design (TDD). Though you could bolt on tests after code but I wouldn't recommend that for many reasons which I won't go into here.

I have found that provided your code is loosely coupled and designed for testability, you are able to move towards an incremental design model in which developers can feel confident making changes and with greater speed.

So what happens if you have a tightly coupled application which might be tested by a QA team but doesn't have any unit tests?

Over the next few articles I'll be outlining some strategies for refactoring your legacy ASP.NET apps

No comments:

Post a Comment