Jeff Atwood’s recent Coding Horror essay, When Understanding Means Rewriting, argues that software developers spend most of their time trying to understand old code. In my experience, that’s true — and not just because as soon as I check in new code, it becomes old code I need to maintain.
Atwood’s thesis is that developers should rewrite code rather than trying to understand it, because it’s difficult to read source code and source code itself doesn’t always reveal the vision or the domain rules behind the project.
At best, that logic is… well, confused.
I strongly believe that so many developers prefer to rewrite code rather than understand it because too many developers cannot read code.
Writing maintainable code and maintaining code are basic skills for software developers. Though they take years to master, I expect a minimal level of competence from even novice developers. If you cannot produce code that a reasonably skilled developer who understands the domain of the problem can maintain, you’ve failed in the secondary goal of producing software.
Why do I bring up the problem domain? I think Atwood’s point about understanding the intention of the software from reading the code confuses his point and leads it astray. If code were sufficient to reveal the intent and purpose and vision of the software, we could do away with either developers (by creating tools to allow customers to express their business rules and generate the software) or customers (because they are unnecessary to set the vision of the project and verify the domain rules through behavior).
Me, I prefer to use customer tests enabled by something such as Fit. Tell me what the software needs to do with something completely separate from the code and I’ll better understand how to explore how the code does that. (Of course, how else are you going to rewrite code if you don’t already understand what it should do? It seems to me that the argument for rewriting presupposes some external mechanism by which you can learn this information!)
Want to improve the state of software development? Take maintenance seriously — write more maintainable code and learn to read and understand code in its full context.