One Simple Change Would Redefine How Software Is Created
August 21, 2012 4 Comments
If Companies would add technical debt to their 10-Qs and 10-Ks, perhaps more people would listen to the clean coders who are pleading for the right tools, the right SDLC methodologies, and the correct investment in software professionals.
For example, consider Google. I took their most recent 10-K and added a line item for technical debt. I have no idea about the quality of their code. My understanding is that they do all night “hack-a-thons” and hire people who consider themselves the best in their field. As a general rule => Large Ego + Lack Of Sleep == Bad Code. I bet this plug number is understated:
Is technical debt a “real number?” It is a real as Goodwill or Intangible Assets. What kinds of companies would have the most technical debt?
- Companies that sell software but make most of their money on support
- Companies that have software assets but make most of their money on suing other companies
- Companies that are 100% dependent on their IT systems but don’t aren’t serious about owning their own code base
A result of reporting the technical debt on the 10-Qs and Ks is that the free lunch of hacking together spaghetti code (usually offshore) lowest-bidder dev shop stops: the income statement gain of lower costs is offset by an increase of technical debt on the balance sheet. And this is not a 1 to 1 relationship, I bet every dollar of savings on the income statement increases technical debt by a factor of two.
Another result is that companies that are hacking together code to get acquired will have their purchase price offset by the mess that they are dumping on the acquiring company. Lower valuations would possibly force companies to get their act together before they are put up for sale. But if their act is together, perhaps they wouldn’t be for sale?
In any event, my guess is that once executives are focused on technical debt and have to confront it as a real number that affects their annual report, companies will becomes more serious about eliminating their debt.
Jamie Dixon's Home 
This post is right on target. I really like the enumeration of the types of companies technical debt should be relevant for. Technical debt is absolutely a real number. The only trouble from a financial reporting standpoint is that we need some standardization around what’s in the technical debt and what’s not. I’m not sure we should be counting the fact that my developers don’t have the latest version of Windows on their desktops, and whether the legacy system doesn’t have full test coverage could be a point of debate. We need some standardization in the industry for technical debt classification and quantification. Especially in light of recent high-profile outages in financial services and airline companies, among others, technical debt should very much be reflected in the financial representation of the company’s health.
Lev Lesokhin
CAST | blog.castsoftware.com
Interesting idea in principle, but think it is completely impractical. Technical debt is real, but the analogy to financials is taking it too far and could dilute the power of this concept, which is the ability to speak clearly about the real headaches that will result from companies who take ill-advised short cuts when building software. But to start squeezing it into balance sheets, I think, is not really necessary. Your Google example is a case in point. It will make no material impact to Google’s revenues or market share from exposing the level of technical debt. I am sure Apple has the same issue with all night hack-a-thons. But the company is doing just fine, thank you very much.
I completely agree with the notion of exposing Technical Debt in the language that shareholders and sophisticated customers understand, i.e. financial statements. TD is a real obligation and like a debt is a charge against future revenues, and as such it is unethical and perhaps even illegal to not disclose it. Further, there are generally accepted accounting principles that can convert defensible estimates of TD into real cash savings independent of software engineering process improvements that might arise from its more proactive management. Roy’s comment suggests that TD arises only from poor practices, but I can imagine circumstances where acquisition of TD, as with financial debt, is not only prudent but strategically advisable. In any case, I agree with Jamie’s point that exposure at the CxO level increases the level of seriousness with which it will be treated.
Pingback: Code Without Thinking » Blog Archive » Your Tech Debt Round-Up