Without going into specific finances, I make twice as much money as I did just 10 years ago. You would think this would be an indication that times, for me anyway, are good; yet I still seem to have the same question every month the week before I get paid, “Where did all my money go?”
It really isn’t rocket science, though. While my income has more than doubled, my debts have gone up at least that much, if not more. Besides the obvious inflation factors (food, gas and entertainment costs have all gone way up in the last decade), there are many other things for which I am indebted. I now own a home, have a child and whereas a decade ago I drove a used car that I paid for in cash, I now drive a nice SUV…that has almost three years worth of installment payments left on it.
Were I to suddenly lose my job or have to take a pay cut like so many others in this economy, there are areas where I would need to cut back. Obviously, I would cut my entertainment budget first followed by other non-critical things. The deeper the cuts went, though, the more I would need to sit down and calculate just which debt could be cut and which was necessary debt.
It is in much the same way that companies need to look at their technical debt and was what CAST had in mind when it performed its calculations in its recent CAST Report on Application Software Health (CRASH) study.
When calculating technical debt in its recent CRASH study, CAST set out to establish a realistic, true-to-business type of approach rather than merely taking the authoritative approach. Building off the methodology of its original software quality study in 2010, CAST made adjustments to enhance and improve the calculation…and according to the architect of the study, Dr. Bill Curtis, they are still open to ways to improve it.
“Our goal is to provide an automated and repeatable process for our many clients to use technical debt as an indicator,” says Curtis. “We provide this information in combination with many technical, quality and productivity measures to provide guidance to our clients.”
As cited in the CRASH report, CAST’s approach to calculating technical debt can be defined by the following:
Great, so now we know how to calculate technical debt…but what’s next?
Technical debt can identify just how much issues with application software are costing a company, but then the question arises: "What do we do with that information?" The answer to is to develop a technical debt action plan that determines how much technical debt can be absorbed before the application (or applications) in question begin to lose their value to the business.
Sounds complicated, but CIOs and heads of applications can start by using an automated system to evaluate the structural quality of their five most mission-critical applications. As each of these applications is built, measure its structural quality at every major release or, if the applications are in production, measure their structural quality every quarter.
In particular, keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the technical debt of the application after each quality assessment. Once you have a dollar figure on technical debt, compare it to the business value to determine how much technical debt is acceptable versus how much is too much based on the marginal return on business value. (A framework for calculating the loss of business value due to structural quality violations can be found in “The Business Value of Application Internal Quality” by Dr. Bill Curtis.)
Calculating technical debt and how to manage it is not that different from managing personal debt; in fact, it can be easier because it is more formulaic.
I sure wish I could just as easily find a framework for calculating the loss of value of my SUV.