Technical Debt

This concept is one I have fought (I mean discussed fervently) with upper management throughout all my technical career. I was never ever to fully quantify it, but instead used my own little adage that went something like this:

I can give you:

• Great Functionality
• A great delivery date
• Exceptional quality

Of course, management would always say, yep, that's it, that's what I want. My comeback, Pick Two!

I never could be very scientific about it, I would tend to lean on some common sense, or the old, Whack a Mole mentality. If you cut the date, either you are going to shortcut the function or the quality. Lets make sure we all understand that it's the date that counts. You have to make the date and have to deliver all the functionality required. How many of you have been involved in this discussion? And of course, what ends up being hit, is the quality. This was especially an interesting parable as the latter part of my career I dealt with High Availability products, you couldn't have poor quality. We managed very well, don't get me wrong, we delivered extremely high quality products. But, this game was part of every release cycle.

As part of my ongoing research, I came across an article written by Ryan Shriver on Technical debt. You can find this article at http://www.gantthead.com/article.cfm?ID=258854

Wow, here it is all laid out. I felt a bit embarrassed to find this term was first identified in the early 90's. Goes to show another one of my favorite quotes, It's what you learn after you know it all that counts.

There are many discussions and definitions here, but as always, pictures talk the loudest:


Technical Debt Chart from Jim Highsmith

Now, looking at this article, many links and recommendations can be found to deal with attributes of troubled development organizations, such as:

• Poor Customer Responsiveness
  
• Long Delivery Times
• Late Deliveries
• Too Many Defects
• Rising Costs
• Poor Morale

Technical Debt is not the answer to all these issues. Process, measurements, and other factors do come into play. But, as I have stated earlier, measurement is the key to everything. If you can't measure it, you can't improve it.

Ken Zaiken

If You Can't Measure It ...

Then you can't improve it. Simple, true, wonderfully profound in its own way, but mainly ignored within the Software Development Community. Software developers consider themselves artists, I understand this, that is my background. You can't measure art, you can critique it, and the market tends to decide what is worthwhile or not. In this day and age, the term is rather overused. At Subway, employees are Sandwich artists, and at the coffee shops, we have Barrista's. But, my degree was in Computer Science, and whether a programmer considers themselves and engineer or a scientist, both of those disciplines require intense scrutiny and measurement. Yet, we seem to have drifted away from that regarding the science of programming.

So, imagine we could come up with a standardize constant measurement lets say a Software Unit (swu). If we had a formalized concept on how to estimate projects in swu's, instead of klocs, person months, etc,. then there would be a way to empirically measure one project against another. Basic software metrics could then be produced that could be used internally and externally to measure how a shop was doing.

For example, productivity becomes: (total project time)/(total swu's). Quality becomes: (total defects)/(total swu's). If we have a quality estimate, then we can set a release standard stating what % of defects need to be removed prior to releasing to the field. Testing coverage could also be defined as: (total test cases)/(total swu's). Suddenly this all becomes very simple, if, we have a constant definitely as this concept of a Software Unit.

Now, this is just not me being the lone wolf in the woods howling at the moon. Carnegie Mellon has a whole department dedicated to Software Metrics, http://www.sei.cmu.edu/index.cfm.

Of course, what would any reference be without the Wiki reference:
http://en.wikipedia.org/wiki/Software_metric. In the Wiki case, I especially like the very end of the reference where once can see the links to Function Points, Case Points, and how to integrate these with newer Agile and Scrum development techniques.

From my experience, leaders will find resistance from programmers who never had their work measured before, but, the organization rewards for planning, estimating, process improvement, quality, and timely execution are tremendous and in the end, once the threshold has been crossed, all parties reap in the benefits.

Personally, I am a big fan of metrics and will always pursue them in every development shop I work with. There is always a way to turn the ship to make these work, despite what opposition one may find.