When I wrote about defending the code, I described how we don’t want to meet a date at the expense of our ability to meet future dates. This applies to future projects as well. If we meet the production date for the first project my producing a shaky pile of code, what is going to happen to the next project using that code base. Some things can be scheduled for refactoring between projects. This approach also requires trust on both sides for it to actually get done. It also only works with selected and specific types of refactorings.
I think this is similar to Robert C Martin’s discussion on the “total cost of owning a mess”. (Also from “Clean Code”.) I like this expression because I think it accurately reflects what happens. Changes get harder and harder to make as does the code mess. They also become more and more risky. Messy code is more likely to introduce bugs when touched. And bugs make the total cost of ownership skyrocket. Which leads to an unfortunate feedback loop where things spiral out of control. So it’s our job as professionals to make sure we do not introduce a mess and encourage our teammates to do the same.
On the other hand, we often have a mess as the status quo. It might have been inherited from the prior author of the code. Or it might have just snuck up on us. When this happens, we can still try to make things better. Even if it’s a tiny bit at a time. Or by not making things worse. It’s so easy to say “well it’s already a mess, so I’ll just add this hack here.” That’s how it got to be a mess in the first place!
—-
Starting in a few hours, we will be hosting Uncle Bob (Robert C Martin) at JavaRanch in the Agile and Other Processes forum. Come on in, ask him a question or join the discussion. You might even win a free copy of the book Clean Code: A Handbook of Agile Software Craftsmanship.
What you touch on here is exactly why on the desktop I prefer a pluggable architecture and on the web side like to modularize and organize packages appropriately to “reduce” this sort of code mess. I also am a big proponent of docing code judiciously… I don’t care how good a developer you are and how much you think you don’t need to, you do!
I also think this is why agile development is to a large part a good thing, although getting managers to agree to the process is futile most of the time. Being able to “rewrite” a section of code, or the entire app, may take longer, but it does a couple of important things, especially to those that have been part of the process. Yes, it may take longer to get each rewrite/iteration out, but the team becomes better aware of the problem domain and has a better idea what was wrong last time and where to correct. In a pluggable app you don’t necessarily have to rewrite everything.
Where this really breaks down tho is when you come in to existing code. I don’t think I am alone when I say I want to rewrite code. It allows me to “own” some of it, rather than maintain someone else’s mess. By owning it, I know it. By maintaining someone else’s mess, I don’t know it, so it takes a lot more time to get stuff done. Jumping around code, figuring out what does what, etc.
My definition of “stealth refactoring” is the process of refactoring a mess whilst including bug fixes and additional features to the functionality hereby reducing the total amount of time taken over the long run without management’s knowledge.
whew… thats a long sentence.
Kevin: You raise a good point about the importance of understanding both the code and problem domain.
Jean: And the best thing is when you can get management to agree!