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.
FIT, a very interesting tool. I was thinking on using FIT under PHP for a web project and found this:
http://phpfit.berlios.de/
Time scales and program performance will often determine if code is to be written in a maintainable way or not. Given 3 days to code a solution which must run in 15 minutes, there is absolutely no use in writing a bit of maintainable code that takes 3 weeks to complete and 3 hours to run!
Programmers must understand that there are 4 audiences of thier code:
1. the compiler
2. the end user
3. maintenace programmers
4. the hardware that the code will run on
Most programmers don't know how to write "intention-revealing" code.
Code that answers WHY the function is doing what it's doing.
Much head-scratching comes from figuring out what the goal of a piece of code is, and (unfortunately) fixing it actually achieve that goal.
"rewriting" is a vague term. If I change a method's name and argument-list from "frpt(int x)" to "printFooReport(FileDescriptor anOpenFile)" is that rewriting?
Rhetorical question - it's the Rename Refactoring applied to make the code more understandable.
With the original naming, the bug in code that did close(x); frpt(x) would be hard to spot.
Cass, how often does that happen? I've definitely written code that way, but it's been rare.
When exploring a piece of code, I find it invaluable to use a debugger and step though the code. This can easily be done with even a commandline-based debugger such as perl -d or gdb.