Most of us understand the idea of, what here in the US, we like to call a lemon in the context of purchasing a car:

A lemon is a defective car that is found to have numerous or severe defects not readily apparent before its purchase. Any vehicle with these issues can be termed a ‘lemon,’ and, by extension, any product which has major flaws that render it unfit for its purpose can be described as a ‘lemon’

We all know the lemon.  Usually the guy who sells it to you looks like this:

And we know the results too.  Unless there is a “Lemon Law” that allows you to return the defective car, what you are given upon delivery is a monstrosity that has maintenance costs that eat 80% of your budget.

When you engage in the practice of loading a software project with undisclosed Technical Debt, you are engaging in exactly the same practice.  You are selling lemons.  This practice of delivering projects with undisclosed technical debt is what I call Technical Fraud.

Technical debt, by itself, is not a bad thing.  Technical debt, as I have pointed out in the past, can be seen as leverage – which in software, allows us to get a prototype up and running quickly, or otherwise express an idea to an audience.  The problem isn’t inherently technical debt, the problem is loading an asset with high amounts of debt.  Of all the issues I have with waterfall software development, one of the biggest ones is that it almost invariably leads to Technical Fraud, especially when done in the context of consulting.

Why is this an epidemic in technology consulting?  Well, when a project is sold, it is often done so on the basis of:

a.) Price

b.) Surface level confidence of the person selling the project that all ambiguities are covered (think of the picture of the guy, above, telling you “everything is fine, can’t you smell the fine Italian leather?”)

If you don’t account for technical debt; and let’s face it, most organizations, despite spending 80% of the software budget on maintenance, do not account for technical debt; you will probably get loaded with it.  It should surprise nobody that Technical Debt becomes the software equivalent of the Enron off balance sheet entity during a Waterfall software project – something not on the balance sheet (not disclosed) that nonetheless, you end up paying interest payments on.

Let me cut to the brass tacks… we need to start accounting for technical debt. We need to have contracts that specify the allowed level of technical debt. And we need to get, as an industry, much better at recognizing technical fraud. Spending 80% of the development budget maintaining buggy software, which blocks companies from taking up new initiatives that might involve writing code, is an unacceptable state of affairs.