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.