Agility and rewriting code

Neil Gunton somehow managed to get Rewrites Considered Harmful? posted to Slashdot. As others pointed out (and the author himself posted on his article), Joel has written a better piece about this same topic. (Joel is an excellent writer, so that’s not really meant as a knock against Neil. I’m certainly not as good a writer as Joel.)

The interesting bit here is the discussion on Slashdot. There were a lot of comments along the lines of “specs can’t go that far in the future” or “sometimes rewrites are necessary because the code is too hard to work with”. Very few people mentioned refactoring, and a number of them seemed to use it to mean “rewriting small parts of the code at a time”.

This is what agility and extreme programming are trying to get across. By having a comprehensive test suite, you’re able to more confidently change your codebase. Because of that, you’re able to do what Ward Cunningham suggests: if it’s hard to add a feature, change the code around to make it easy to add the feature, and then add it! If all of your features are added this way, your code will be much cleaner and more maintainable.

Rewrites may still be necessary over the long haul, if there is a platform shift. But, even then, assuming you’re not moving to an altogether different programming paradigm (like procedural to OO), you can probably just port a well-designed system to the new platform.

The point is that you need to bake in the ability to accept change from day one. As long as your code is ready to be changed, learning a better way to do things is just an opportunity to move the code up to the next level, step by step. It’s not a cause to rewrite.