Ongoing Maintenance & Debt Reduction

I don’t like like analogies or metaphors most of the time, they’re weak logical arguments; I try to avoid them. Recently, I’ve seen many weak analogies that don’t really put things into real perspective. Comparing Star Trek to software development is probably not going to give somebody a good understanding of the situation; especially since:

  • Star Trek isn’t real
  • Even people who are aware of it, aren’t familiar with all the alien races in the shows

That’s my little rant on weak analogies. I’ll be using my own later, so call me a hypocrite, I’m fine with that. Better examples include “Professionalism and Thermodynamics” and even non-comparisons like “Paying Down Your Technical Debt”. Here’s my stab at an analogy that (still weak) is likely a bit more easily understood.

Keeping your surroundings tidy

It’s natural for all things to become messy or dirty over time, this is entropy defined, there are exceptions of course; maintaining software is not one of those exceptions. The only way to keep things organized is to put energy into sustaining some level of tidiness. This can be seen (here comes my weak analogy) in a messy room, a dirty garage, or an aging vehicle. By taking care of these things on a regular basis, you’re much less likely to run into the problem of:

“Wow this is a disaster! It’s going to take days or weeks to get this baby back to normal!”

When adding a new feature to your application, you may uncover a weakness that had not been seen until some code was required to be added/changed. At the time, it may have seemed like the best implementation. Your code is growing now and your “garage” is probably getting messy.

Not Just Spring Cleaning… Clean that Garage Weekly

So just like the garage, that takes all weekend (or more) to clean up, your application will get to a point where a spring cleaning isn’t good enough. It will become hard to maintain and add features to, because you can’t get to where you want to be without tripping over something.

Reduce, Reuse, Refactor

Much like Earth-friendly “green initiatives” that promote Reduce, Reuse, Recycle; I think an application can benefit from a similar motto:

  • Reduce : Delete unused methods and variables, remove commented out code. This should be done every time you commit. Remember, cleaning this up later is going to take extremely longer than if you do it regularly.
  • Reuse : Combine common functionality wherever possible (software’s version of recycling). Oftentimes this will lead you right into the refactor portion.
  • Refactor : As your application matures and adds new features, keep refactoring it and ensure you’re not falling deeper into Technical Debt.

Uncle Bob put it nicely when he compared it to a Boy Scout motto:

“Leave the campground cleaner than how you found it.”

Yes, It Takes Work

If anybody tries to convince you that clean code and reduction of technical debt is fast and easy, they’re not being honest with you. Refactoring your application can take a lot of work if you don’t have sufficient tests around it. You need to make sure that you don’t break anything. The more confident you are in your application working, the easier it is to modify it for the betterment of the project.

Maintenance of your code is probably hard to sell to upper management and project owners. If somebody doesn’t have the technical background of writing software, it would seem like “wasted time” because they don’t “see” a benefit. By “see” I literally mean “see”. The application doesn’t look any different or add new functionality. I don’t have a good answer to this yet, but I’m working on it. In the meantime, these posts seem to answer some hard-to-answer questions and concerns.

About Chris Missal

Oh hey, I'm a Senior Consultant for Headspring in Austin, TX. I've been working in software professionally since 2006 and I really, really love it. I'm mostly in the Microsoft world, but enjoy building computer things of all sorts (to be vague). When I'm not slinging code, I'm probably out and about slinging discs, bowling balls, or good beer with great friends.
This entry was posted in Best Practices. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Good post, I think your analogy works fine. What are your thoughts on signs that point to rewriting instead of refactoring, or are you considering them one in the same?

  • @Sean

    I’m not really addressing a rewrite. If an application gets to point, it’s probably considered a failure.

    I would hold off on a rewrite until there is no option. We just went live with an e-commerce site that was an entire rewrite. In hindsight, we probably could have done more with the existing application, rather than scrapping it all together. The old app (which the entire team inherited) had no tests at all and was to a point where no change could be made with any level of confidence in not breaking existing functionality.

    I think we did make the right decision to rewrite. I would think that our case was pretty rare.. maybe not, but in my experience I haven’t seen anything get to that point though.

  • So the house equivalent of the rewrite would be… lighting your house on fire and building a new one to fix a wretchedly disgusting house? Something like that, anyway.

    And refactoring to a truly more maintainable design might not be merely cleaning, but actually throwing out some of the excess clutter so the place is easier to keep clean in the future!

    Ok, I’m officially thinking about this too much.

  • @Anne

    You know how when they blow up a house only to rebuild a new one on Extreme Home Makeover? Who really does that?! It doesn’t make sense just to blow it away and start over.

    With our site, we couldn’t just blow it up and start over. We had to maintain the old, while rebuilding the new one behind the scenes.

  • I think the analogy works pretty well.

    If we are walking through a room and notice a piece of dirty laundry, or a book/game/novelty/dvd that is out of place, and take the time to tidy one or two little things along the way, it is much easier to keep the house organized over the long wrong without having to plan a huge cleaning event.

    If we continually leave all these little things for Spring cleaning, the clutter begins to compound – maybe even to the point where it is much less costly to blow the house up and rebuild rather than clean up the disaster.

    Occasionally, we’ll run across a situation in which we notice something is not under test coverage. As you point out above, this is a critical issue. Making the time fix that, as close possible to the time we discover the omission, will also help avoid the decay that so often accompanies long-maintained applications. Sort of like reorganizing a cupboard to make room for something new or something that was overlooked before: not quite as easy as a quick tidying up, but a lot less expensive than ignoring it and having to deal with the pile that tends to grow behind it as a result.

    We could probably avoid having to sell a lot of this maintenance to upper management if, as you suggest, we just tidy little things up along the way every time we touch the code. At a minimum, we’ll certainly make the big job a lot easier.

    Hope I didn’t take the analogy too far! On the one hand, it seems so obvious. Yet, often I get so focused on getting done what I’m in there to do I just ignore those little things that are out of place, thinking I’ll get to it later.

    This activity, while useful and necessary isn’t a silver bullet that will solve all our technical debt woes. But, to me it is one critical component to reducing its accumulation.

    It’s a mind set, an attitude, a commitment that takes time to become habit. IMHO. And I’m still working on it!

    Good post. Good reminder.

  • Dan Covill

    It is sometimes difficult to get approval for ‘wasting your time’ on cleaning things up. A great time to do cleanup is when you’re asked to add/modify functionality. The ‘cost’ of maintenance disappears, the new feature gets added, the system runs a little better, and everybody’s happy.

    In my (long) experience, the chief impetus for starting over is that people don’t want to dig into the existing system to see what it’s actually doing – i.e., intellectual laziness. The problem is that you’re missing an understanding of the problems the existing system solved, so you will almost certainly create them all over again. Even a drastic rebuild is almost always better than starting over.

  • @Dan

    The problem with doing those things without approval is that they’re not given proper visibility, therefore they probably aren’t known to be as important by management. I’d like to see some of my projects given time to address these issues, not just me taking care of them “after hours”.

  • Thanks so much for the taking the time to post this information. With the economy the way it is right now with all the layoffs and more to come; government spending and deficit out of control; the continued housing slump; one wonders where to turn for help. It sure is nice to know that there are people out there like you that can help folks such as myself. Thank you.