Sunday, May 31, 2009

Containing technical debt

One of the most important concepts in Software Engineering is "Technical Debt." It was first introduced by Ward Cunningham in 1992 in an experience report at the OOPSLA. If you haven't heard the term before or want to refresh your memory, I have collected articles/blogs on the topic that I thought have done a good job of explaining it.
  • Here is Ward Cunningham explaining his thoughts behind why he coined the metaphor on wiki and also in a video talk.
  • Here is a blog by Martin Fowler on the topic.
  • Here is a personal blog by Dharmesh on the same topic.
I was at an Open Space session on technical debt at Orlando Scrum Gathering early this year. What seemed to be on everybody's mind was how to protect our projects from going bankrupt under the burden of technical debt. We all agreed that it is easy to deal with debts that we take on knowingly. The real challenge is to identify debts that creep up on us over time (like credit card debt- a little here, a little there, some missed payments, and voila...). We get caught by surprise until it is too late.

I am going to suggest a few things when put into regular practice can help you contain the debt to a minimum.

1. Low test coverage can contribute to hidden technical debt. When we are under time pressure, guess what gets cut from the budget? "testing!" It may seem innocuous to eliminate funding for "testing," it can push the project to bankruptcy when done on a regular basis. So, target 90%+ test coverage and track it through continuous integration.

2. The best "architecture" is not static, it is evolutionary that emerges over time. What is important though is "consistency." If we are always doing the same thing the same way, the chances of incurring hidden debt goes down. The consistent way of doing things needs to be a shared knowledge best captured as a list of "How Tos" and needs to be kept in synch with the evolving architecture. Do you have one such list for your project?

3. Review architecture at a regular interval to spot inconsistencies. I am sure you will find some even after you have a published "How Tos." As soon as you find them, fix them.

4. I have seen bugs are triaged and then some are deferred to be fixed in the future in favor of some "important" new features. The fallacy lies in the notion that cosmetic/minor bugs are harmless. What is harmless today can compound into a significant issue later somewhere else in the system. Personally, I always like to fix all bugs before I do any new development. However, I can understand that we may need to do it at times, but it should be "exception" than "norm."

5. Last but not least, if you must take on a debt, get a commitment to payback in full by a specified timeline. Then track and report on it like a hawk (not like the Fed or SEC).

How are you containing technical debt on your project? Care to share?

No comments:

Post a Comment