How to Guarantee a Code Rewrite

Jun 27, 2007

Like everything else, code tends to move toward increasing entropy. But software developers tend to like things nice and orderly, because being able to maintain your code is a good thing. Software (unlike hardware) rarely lives in a sealed box, and will mostly like be patched, upgraded, changed frequently. Unfortunately most of these changes are made as quick hacks due to the nature of people wanting things yesterday, or the day before that if at all possible.

After a certain period your code will make you queasy, and when at that point the overwhelming urge to rewrite the whole thing becomes almost impossible to ignore.

Everybody loves a rewrite. You get to correct past mistakes, do things “the right way”, and finally get to attack all those warts that were the result of that last quick fix before the latest release.

(Chad Fowler has written several pieces about the inherent danger of the rewrite.)

How to Prevent a Rewrite

As a developer your goal should be to prevent the rewrite at all costs. It may seem like fun at first, it will become painful, especially if you have a tight deadline.

So how do you prevent your code from being tossed and rewritten? It’s easy.

Write readable code.

Really, it’s as simple as that. Your code should have plenty of whitespace, decent layout, comments … you know, all that stuff you know you should do, but never really do. If your code isn’t readable then it’s only a matter of time until it gets yanked out of the repository and rewritten (many times by yourself).

No matter how slow or buggy your code is, as long as people can understand what in the world is going on there’s at least a fighting chance that a much easier refactoring will happen instead of a complete rewrite.

It doesn’t matter what language you are using, even verbose monsters like Java can result in well written code that be read cleanly. So please, write readable code, because someone is going to have to look at it one of these days.