A.K.A. The Version 3.0 Myth. A.K.A. The Rewrite Myth.

I recently overheard a developer telling his manager a variant of what I call “The Version 2.0 Myth”, it went something like this:

If I could write this module again it would be half the size and so much faster… It would be worth doing just to fix all the bugs

Sensibly, his manager didn’t take him up on the this idea; this promise which seems to persist in development circles of a mythical “Version 2.0” that delivers improved efficiency, cleaner code and no bugs.

I’ve also heard it as the Version 3.0 Myth, where Version 1.0 is ugly and buggy, the second version is over-engineered and the 3rd… the 3rd is a masterpiece of software craftsmanship!

Here’s why it’s never so…

The 4 Realities of the re-write

1. Products don’t stand still. Even if you were given the weeks or months required to rewrite the code the product will move on. This either leaves your Version 2.0 out of date at release, or more likely, subject to change while you’re rewriting and I guarantee that the changes don’t fit in to your original vision.
2. Nobody’s perfect. Version 2.0 won’t be bug-free, it will be full of bugs no one’s found yet.
3. If you suggested a rewrite you’re not the person for the job. And did you write Version 1? Why should I think that you’re suddenly capable of producing better work?
4. It’s a waste of money. Who’s paying for this? Do you really expect the company, customer or investors to pay good money for the product to stand still while you make things a bit nicer for you.

You can re-write if you have a good business reason

There are good reasons for throwing code away and starting again: significant changes to a feature, changes to code that is so obscure no one can determine how it works, moving away from legacy frameworks or languages, fundamental flaws in security or scalability.

What these reasons all have in common is they are driven by a business benefit.

Increment instead

The solution to this problem code is not to rewrite for the sake of it but to incrementally reach to a better solution over multiple features in multiple iterations. Tackle the problems when business changes require the code be modified and only then, this way it is the business deciding what to spend effort on, not just the development team.