Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.
There are two categories of technical debt: intentional and unintentional. For either of these two types of technical debt there are usually positive short term consequences (due to early delivery) and negative long term consequences (due to a low quality standard of software). Despite this similarity between unintentional and intentional technical debt the distinction of their causes needs to be made in order to reduce the prevalence of this quality killing phenomena.
Intentional Causes of Technical Debt:
- Time constraints placed on development
- Source code complexity
- Business decisions which lack technical knowledge and make communication difficult
Unintentional Causes of Technical Debt:
- Lack of coding standards and guides
- Junior coders with little experience and poor skills
- Lack of planning for future developments
The long term effects of the above are longer work hours, error and bug prone code, customer dissatisfaction, and increasing source code complexity. There are several processes that can be set into motion in order to keep technical debt at bay, or to address it before the negative consequences of it reach untenable levels.
- Bug fixing days
- Code Reviews
- Clear coding standards and guides
- Communication between business, management, and developers
While up until this point, the post does a good job of delineating the common causes, effects, and resolutions of technical debt – it is missing a key factor that would lead to the successful management of technical debt in any organization. Many of the causes of technical debt outlined above are a result cultural issues.
Unrealistic time constraints, green developers, little or no coding standards, and poor communication with the management are results of a method of operation for a business. For example, developers with little experience need to trained in order to reach the standard of work that is expected and needed for the business to thrive. Notice that in this instance there are two things needed: a clear set of standards and sufficient time allotted for training. These two items by themselves are causes of technical debt. Therefore, there is a clear connection between one cause of technical debt to another, and often times one is not present on its own. If there are unrealistic deadlines in an organization there are probably also untrained workers, non-existent standards, and a lack of communication with management to solve these other problems.
No cause of technical debt exists in a vacuum – and in order to address it there needs to be a conversation on why it is occurring and an understanding of what needs to be done to deal with it. If time constraints are a serious issue in an organization because management wants quick releases – the cost of these unrealistic time frames needs to be explained. If this exchange does not occur the cycle of poor quality code and technical debt build-up will continue.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.