Code Rot, Technical Debt, and Refactoritis

Code rot.  Technical debt.  Call it what you want – it’s essentially the same thing.  Over time, code becomes more and more of a mess, and developers want to work with it less and less.  If the code smells, no one is going to want to work with it.  That’s fair – no one wants to live in the house next to the sewage treatment plant.  But it doesn’t need to be that way.  Code doesn’t need to smell.

Software development is unlike almost any other industry out there.  We have so much flexibility, yet we seem to so often fall into the same traps – again and again.  One of these traps is not spending an appropriate time on maintenance.  We write systems, then come back to them six months later, after something breaks.  Since then, everything has changed, and the original code no longer does what it is supposed to be doing.

Imagine this: It’s the year 1916.  You’ve built a brand new house with the latest amenities – complete with indoor plumbing and heating!  Now keep the house the exact same, and fast forward 100 years.  Even if you managed to perfectly preserve the building materials, I don’t think too many people would want to live in such a house.  There’d be no electricity, no double-paned windows, no high efficiency furnace, and gasp – no internet!  Even if the house was in perfect condition, it no longer meets the needs of those using it.  Unless the occupants are also 100 years old, in which case you’ve probably got bigger problems.

Code is like this.

Even if a piece of code doesn’t change, everything else around it will inevitably change.  Technologies develop, related systems get upgrades, and business requirements change.  Rarely does something in software stay static for multiple years – let alone multiple decades (or even months!).  You need to occasionally make a few tweaks here and there, re-write the occasional function, update documentation, add additional unit tests, and so on.  You need to spend a little time doing some proper maintenance, and occasionally add a new feature here or there to make sure that a given system is meeting business requirements.  Routine maintenance is critical to keeping systems operational.

The other extreme of a lack of maintenance is something I like to call “refactoritis”.  This is something a lot of developers suffer from.  Once a particular problem is well understood, and a system is written, a developer with refactoritis will want to immediately refactor it.  It’s a dangerous, slippery slope.  There’s nothing inherently wrong with refactoring code – just like there’s nothing inherently wrong with open heart surgery.  But there is a problem with it when it is done without reason.  It’s a difficult itch to scratch, and once you’ve refactored one thing, you’ll want to go on to another… and then another.  And before you know it, you’ve blown through all your time just re-writing the same few pieces of code again and again, and nothing actually gets done.  Client requirements still aren’t met.  People get angry.  Bad things happen.

So how does one find balance between the two?  Experience.  Either your own or someone else’s experience can be amazingly helpful.  This includes guidance from more experienced developers.  They will know when to push back to get more time to do a bit more maintenance, but they will also recognize when it’s time to move on and work on other features.

Don’t let your code rot.  But don’t catch refactoritis.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s