Technorati Tags: Software Architecture,technical debt,credibility debt

The term "technical debt" is used by managers to describe a development team’s situation when it has not consistently met the defined quality goals for the project.  They use the phrase "paying down our technical debt" to describe the time lost in bringing a project up to the defined quality standards.

 

In a way, it is an accurate phrase that I can live with.  On the other hand, it leads me to believe that we have another type of debt that is more serious: credibility debt.

 

Projects are usually difficult to get moving, and everyone wants their project to be "by-the-book" of whatever methodology has been chosen (or hacked together from the current methodology-du-jour).  The problem is that most projects actually start moving into development before the quality standards have been completely defined, and adding those definitions at any point after the start of development imposes an artificial level of "technical debt" that must either be paid off or ignored. 

 

Zealous development managers tend to want to halt development to pay off this debt, especially since they are the ones typically defining the quality standards.  Hearkening back to your economics courses in college, you'll remember the term "opportunity cost", which is the oft-overlooked component of the technical debt equation.  So the cost of fixing technical debt looks like this:

 

    TOTAL = Cost to fix actual technical debt + Cost of project delays (opportunity cost) + Cost of slowed (halted) project velocity

 

So, you've decided to pay off the debt, and now you show up at your next checkpoint/demo/etc meeting and have to explain to the product owners that you've decided to delay their project that you've been entrusted with to meet a new set of quality goals.  Their first question the PM then asks is "Was there a problem with the quality of the product?"  In most cases, especially near the beginning of a project, that is not the case.  It is more about the dogged pursuit of the "ideal" that often gets in the way of real progress.

 

This brings me to the point of this blog entry:  your credibility is the biggest asset or liability you have. 

 

Credibility is a subjective measure that you can affect, but is ultimately assigned by every person to another.  Think about your team for a minute.  Now think about the next important task you have to assign, and regardless of current work assignments you know there are some people you can absolutely trust with the assignment and that there are some people you would not trust without significant oversight.

 

The same is true for development managers and architects.  If project management gives you a task and you incur significant "technical debt" early on in a project, that is likely to be applied directly to your credibility credit.  The good thing about credibility debt is that it can be paid off as well, but not nearly as easily.  A successful and strong finish to the project goes a long way towards paying it off, and hard work and planning to minimize the buildup of technical debt shows management that you are managing the situation well.