Editorial note: this post was originally written for the NDepend blog, and you can read the original here. If you like the topics of static analysis and code metrics, there’s a lot you’ll love over there.
Editorial update: due to the unanticipated popularity of this post and the fact that I’m buried in work the first half of this week, I’m planning to write a detailed follow-up addressing some of the sentiments in the comments that I’m seeing. That will be on the NDepend blog, where the original appeared. Stay tuned, if you’re interested in follow up, and thanks for reading/commenting!
“We can’t go on like this. We need to rewrite this thing from scratch.”
The Writing is on the Wall
These words infuriate CIOs and terrify managers and directors of software engineering. They’re uttered haltingly, reluctantly, by architects and team leads. The developers working on the projects on a day to day basis, however, often make these statements emphatically and heatedly.
All of these positions are understandable. The CIO views a standing code base as an asset with sunk cost, much the way that you’d view a car that you’ve paid off. It’s not pretty, but it gets the job done. So you don’t want to hear a mechanic telling you that it’s a total and that you need to spend a lot of money on a new one. Managers reporting to these CIOs are afraid of being that mechanic and delivering the bad news.
Those are folks whose lives are meetings, power points, and spreadsheets, though. If you’re a developer, you live the day to day reality of your code base. And, to soldier on with the metaphor a bit, it’s pretty awful if your day to day reality is driving around a clunker that leaves car parts on the road after every pothole. You don’t just start to daydream about how nice it would be to ride around in a reliable, new car. You become justifiably convinced that doing anything less is a hazard to your well being.
And so it comes to pass that hordes of developers storm the castle with torches and pitchforks, demanding a rewrite. What do we want? A rewrite! When do we want it? Now!
At first, management tries to ignore them, but after a while that’s not possible. The next step is usually bribery — bringing in ping pong tables or having a bunch of morale-building company lunches. If the carrot doesn’t work, sometimes the stick is trotted out and developers are ordered to stop complaining about the code. But, sooner or later, as milestones slip further and further and the defect count starts to mount, management gives in. If the problem doesn’t go away on its own, and neither carrots nor sticks seem to work, there’s no choice, right? And, after all, aren’t you just trusting the experts and shouldn’t you, maybe, have been doing that all along?
There’s just one nagging problem. Is there any reason to think the rewrite will turn out better than the current system? Read More
