I was recently asked by a businessman to explain the concept of technical debt – and why it matters to him. He owns a middle-sized company that has nothing to do with IT except as a client/user. The text below was inspired by that discussion.
Software quality can be divided into two major aspects:
- functional quality and
- structural quality.
Functional quality means that software (system, application, game etc.) does what it is supposed to do and doesn’t do what it is not expected to do. Structural quality is how well the product is built and it is a function of many elements that can be collectively described as presence of good engineering practices or their absence.
The problem here is that functional quality can be fairly well assessed by the client / user of a software product. Functional quality deficiencies – defects – are plainly visible to the user as various forms of unexpected behavior. Those range from inability to perform functions users expected through corrupt data, incorrect calculations to unexpected error messages, hang-ups or resets etc.
Structural quality deficiencies, however, are not directly visible to the client. They are visible only to experts – developers – once they have access to the source code and try to modify it. A code of good structural quality is relatively easily understandable and thus modifiable. Conversely, a code of poor structural quality is very hard to understand and therefore modify, sometimes to the point of it being impractical and requiring a full re-write. Structural quality also influences functional quality. When working on a product with poor structural quality it is harder for developers to capture functional defects before they are released.
Therefore poor structural quality of a software product can be hidden from users, but only until they require further modifications and ongoing development. Then it is visible as high cost of those modifications. If the problem is not addressed this cost is rising with time, at the same time the functional quality deteriorates.
The problem here is that most software currently operated (especially business software, SCADA systems, large scale ERP systems etc.) was developed with traditional processes where both the scope and cost/time were fixed before work started based on some initial estimates. The complex nature of software development makes such estimates highly unreliable, but the logic of the bidding process drives final bids down. As the result development teams are very frequently put under pressure to deliver a product against unrealistic deadlines. Since both scope and date are fixed the only recourse left to them is to compromise quality. Because functional quality is visible to the end client the part that gets slashed is structural quality.
If the product is developed once and then never modified the results of poor structural quality may be negligible. However, if the development is ongoing – as is usually the case – the poor structural quality impedes the teams as they continue their work on the product. If steps are not taken to address the situation, monitor and improve structural quality the teams spend more and more effort on fighting with the existing codebase rather than developing new functions. This is a fairly typical situation in many companies with older products (consisting mainly of what is known to developers as ‘legacy code’).
How that looks like from the business perspective? As time goes by for unit of time / expense spent on development the business gets less and less new functionality as more effort is expended fighting with ‘legacy code’. After certain point schedules frequently slip (scope is not delivered on time) and number of defects released to production increases. This leads to dissatisfied customers, rising maintenance costs and eroding competitive advantage. Details slightly differ depending on whether the software in question is a product sold on the market or used internally to drive business processes, but the net effect is always the same – poor structural quality of software stifles business. If situation is not addressed it may even bring it to bankruptcy.
The term “technical debt” has been used to better describe this phenomenon to non-technical decision-makers. By not doing some work needed to maintain high structural quality (for example to meet an imposed deadline) teams take on “debt” – they appear to work faster, while in fact they just skip work that will have to be done at some point. As with financial debt there is an ongoing cost of “servicing” it (increasing difficulty to modify and extend existing code). As with financial debt if it is not kept at bay the cost of servicing it increases with time to the point where it eats all the money spent on development. This is when a complete re-write of the software is the only solution left.
To sum it all up:
- in software there are two components of quality – functional and structural quality,
- poor functional quality is visible to the client immediately, effects of poor structural quality take some time to become noticeable, but once they do the impact is high and rising with time,
- the business is impacted by increasing maintenance cost and decreasing speed of developing new features – it takes longer and longer to get modifications and extensions completed,
- if not addressed situation can get to the point where the only practical way out is a full replacement of the system/product in question.
As an interesting side-note: if teams are frequently working against unrealistic deadlines made up by management or sales and forced upon them the result is a culture of poor quality. That is – employees feel it is acceptable to produce software of poor quality even if at a given moment the pressure is not there. This is where the culture directly and demonstrably impacts the business.