You can’t say you’ve climbed it until you’ve reached the peak, it doesn’t count unless you ship it. To get to the point where someone pays something for your software, there’s a lot of leeway and like a chess game many small moves that will affect the outcome. You can cut corners, drop features, play with resources, all of which define the history of the application and start adding technical debt. Behind every line of code is debt; wages, premises, capital equipment that someone will eventually pay for.
Technical debt is one of those intangible things that make or breaks an application, sometimes whole companies. Unfortunately it’s one of those things that I think software engineers as a profession don’t do well in conveying the importance and long term effects of. It’s often impossible for outsiders to understand the difference between a quick hack and rigorously tested application as they can appear to be exactly the same thing. Shipping software isn’t a rigorous scientific process and offers a lot of flexibility in getting to and even defining the end point. The call to arms here is that developers must get better at informing users as to costs and importance of technical debt.
Businesses and accountants are already familiar with the fact that the actions of a business can have an affect on the overall success of that business. When a business is acquired there is an allowance for good will. Favourable things the business has done that values the business more than it’s books report. While it can be haggled over, a business with loyal and repeat customers leading to a steady income stream is much more valuable than the one with occasional and sporadic customers despite the fact they may have the same value of assets and liabilities. So most sales, financial and management staff are familiar with the goodwill concept and I find it’s a good basis to sometimes assist in conveying what technical debt is and the affect it can have on their balance sheets. It’s also reasonably intuitive to a wider audience.
I like to think of technical debt as negative goodwill. Carry too much technical debt and the ability to deliver new features and customer satisfaction diminishes, which for a software company, reduces it’s viability and success potential. Technical debt is not an incidental, it’s a critical factor for the long term success of a software company. If your software cannot address customers needs and cannot be delivered in an acceptable time frame or cost then the business entity will soon cease to exist. This is why quantification of technical debt is so important, it may be vague, but until you’ve attempted to understand the costs of a decision, you can’t trade them off in a knowledgeable manner. I think a lot of poorly performing products are a result of people not fully understanding the technical debt they are accruing. Every piece of code has technical debt, this is expected and fine as long as the debt can be serviced by the organisation.
One pertinent example I like to use is that technical debt can spiral out of control just (well kindof) like the sub prime meltdown. There were lost of small loans (modules) which were very risky. Individually they were comparatively small amounts of debt so were manageable and were an acceptable debt. Agencies then bought up and packaged into larger units (made into an application) all of the smaller debts and mixed them with less risky debts which meant that the ability to see and quantify the real cost of the debt was lost. This tends to be true for applications, internally they may be sawdust, glue and paper, but on the outside it looks the same as every other application, so appears less risky that it really is. When conditions changed aversely in the market the true debt and risk became apparent and it all fell apart very quickly in a cascading manner. A good deal of the ramifications of the sub prime crisis extended beyond the US as outside bodies that had previously had good governance and risk management were unable to quantify and understand the real cost and risk of the debt. If you want to avoid a subprime meltdown in your own codebase it’s important to understand, quantify and actively manage technical debt.
So how do you measure technical debt? The first things is to acknowledge that it’s a nebulous concept and it’s really about estimation. You can live with an untested and poorly implemented piece of code or library but it’s going to be a source of errors for customers until you fix it. If you want to quantify the technical debt, start planning the project in your head to fix it in the next release. You’ll end up with costs like; the cost to write the new software in resources and time, the cost of ongoing support and fixes, the cost of developing patches and hotfixes, … . I like to use the thrown estimate model, pick a task, get a few wise heads, and each come up with an estimate in workdays then take the average.
Basic risk management techniques are also useful. Severity x Probability = Cost. Something terrible like a bug that causes 10% of your customers to lose data might be exceedingly rare, but the cost is monumental. Having code that could cause this because of a lack of investment in testing would be a high technical debt cost very few businesses with customers could afford. The more contingencies and planning you can do, the better you’ll be in a position to understand the real tradeoffs and convey that in terms that business understands. It’s also worth noting that you can go overboard, at some point you do need to ship, and not shipping also has a huge cost.
There’s much harder examples that don’t really lend themselves to quantification, for example; what is the technical debt of a product where getting user feedback is too slow, what is the cost of a hacked together and non intuitive user interface? My favourite at the moment, what is the debt of having distributed development teams in different timezones? The main thing is identifying what, if any, debt is being caused. It may not be able to be quantified specifically, but it’s often intuitive to people that something can have a intolerably high cost and must be addressed. That is, if the UI is just rushed out without proper feedback and testing cycle people won’t buy our software as it’s non intuitive and ugly and we’ll get poor reviews. If our install is terrible because we didn’t have the knowledge and didn’t sit down and plan it, then despite the fact our software is great, people won’t ever be able to install it, hence won’t know that.
I find thinking about choices in terms of debt and trying to quantify the costs often helps also cost the solutions. Eg What is likely to happen if there’s poor communication in distributed teams -> disjointed and poorly performing software with a high ongoing maintenance and rework cost -> what is the cost of outfitting a room in each location so people can do daily face to face meetings? and so on. In debt terms it’s just as important to cost the solution which is easier in some cases as it’s specific actions which usually means someone has to pay for it. There’s always the choice of doing nothing and you don’t want to start something if the future debt will be higher than the foreseeable benefits or that you can manage. What is the debt of the decision you are making when you write that line of code or choose that architecture?
This may sound like it’s a lot of overhead but not every decision needs to be quantified. Every dog has his day and every project has points where a decision which will define the success of the software has to be made. It tends to involve meetings with business owners, senior management and users. Going into the meeting with the options and quick dot points about the future costs and debt associated can really help to focus on getting the optimal decision.