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?

Monday, May 18, 2009

The Dream Team of Agile Software Development

If you had to put together the best team possible for the most complex project and money is not a concern, who would you have on your team? I can tell you who would be on my "The Dream Team."

Product Owner- Mike Cohen

Scrum Master- Ken Schwaber

The Development Team

Kent Beck
,
Bob Martin,
Jim Copline,
Martin Fowler,
Alistair Cockburn,
Ward Cunningham,
Jeff Sutherland,
Ron Jeffries, and
Jim Highsmith

I am making an assumption that they all still write software and will be able to work with each other...:-) Now the questions are-

  • Is this team going to be the most hyper-productive team ever in the history of software industry?
  • Are they going to follow Scrum? Or, are they going to come up with something new? Should we call that "Scrum But?"
Just wondering. Unfortunately, the reality is much more constrained. We need to work with a team that we can reasonably put together. The reasonable expectation is to have individuals who are average. I always wonder why people are so obsessed with hiring the best/brightest from Standford or MIT. I guess I do not fall in that category (and hence the grape is sour!)...:-) However, I sure can bet my money on my team that it can go head-to-head with any dream team in the world. I am sure so is yours.

The focus should be "The Team," not the individual. Do me a favor, when you look for a new team member, mention in your Ad- "Looking for the best team member."

What do you think? Who would be on your dream team?