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.

A Lesson in DRY Learned with jQuery