Pavel Kaplunou
, If you are a CTO, software engineer or are in any way related to coding, the definition of technical debt will be a familiar one. Yet, for key decision makers, project executives or figures somewhat removed from computer programming, the concept of tech debt may be a useful one to grasp. This is especially the case if you are about to embark on your next IT project and are rightfully thinking about your bottom line.
What is Technical Debt?
Tech debt is often perceived as the work that accumulates when development decides to forego a solution that would be beneficial in the long-term in favor of a more immediate one. It can be measured directly in the time the software rework will take to eliminate the it. The notion is closely associated with increased code complexity and overall reduced maintainability of the software.
Abandoning bug fixes to focus on feature development or because changes in the codebase can lead to more unprecedented bugs are two causes of deliberate technical debt. But there is more to it than just that the efficiency vs efficacy dilemma. Technical debt is also the result of everything that was not originally accounted for at the software design stage.
To illustrate the case: a software system is designed to support a certain number of features and maintain a specific performance level. The system does exactly what it was intended to and does not need to be scaled. When a new slew of features is introduced, the original architecture is all of a sudden not flexible enough to support them. The system now needs rework to maintain the desired performance. However, had the decision to introduce new features not been made, no debt would be formed.
Technical debt is also the result of everything that was not originally accounted for at the software design stage.
Misconceptions and True Causes
Misconception one: New features that have no compatibility with the original architecture automatically constitute debt.
False to think of them as such before the decision to add them is made. An architecture’s design and peculiarities become a technical liability after you make the decision to add new features. This requires as much thought from the business point of view as it does from the technical in deciding whether such features are worth adding at all.
Misconception two: There are numerous bugs and flaws.
If for the end user the software lives up to its original purpose, the user experience is unchanged and the perceived value of the product remains unaffected, despite them, – there is no debt.
Misconception three: Absolutely all necessary changes arising from one minor change become debt.
Whatever technical perfectionists and over-optimizers may say, it may indicate the emergence of tech debt. Yet it is not enough to fully classify it as that.
Contributing factors are composed a lack of technical skills of the development team, poorly formulated requirements and the wrong technology stack for the job.
Like it or not, technology obsolescence is also a thing. There is no running away from legacy code or software erosion. But is there a human factor involved as well, you might ask?
In a podcast, CEO of Marketing Insider Group, Michael Brenner said, “Behind every idea is an executive that asked for it”. This is where the managerial team comes in. Calculating, or rather under- or over-calculating, the lead time budget affects the likelihood of tech debt. In the majority of cases, it is the executive decisions that lead to technical bankruptcy.
In terms of a product’s quality attributes, from a business analysis point of view, both internal (Efficiency, Modifiability, Scalability etc.) and external (Performance, Security, Usability etc.) quality attributes can suffer as a result of product design miscalculations.
An architecture’s design and peculiarities become TD after you make the decision to add new features. This requires as much thought from the business point of view as it does from the technical, to decide whether such features are worth adding at all.
Impact on business
While the connotation of technical debt is most certainly a negative one, it is not always as critical as it may seem. Solutions created by IT-centered businesses oftentimes generate more value to customers that outweighs the initial investment or costs of maintenance.
Only if the product is not up to par with the original vision, it will reflect on the bottom line. Introducing re-designs and changes can stack development bills and result in inefficient time use. The real dangers facing software products lie not in technical debt, but in high customer churn, security issues or overall poor UX.
If worst comes to worst, the software system simply will not be able to handle the user flow. Neither will new and promised features meet deadlines.
In the best case scenario, it will be the development team that will be dissatisfied. This will mainly occur because few software engineers like to deal with code that resists change, especially if that code is not theirs. But code refactoring is important to save time, money and effort and should not be ignored, especially by long-term projects that need to adapt to changing market requirements.
The real dangers facing software products lie not in technical debt, but in high customer churn, security issues or overall poor UX.
When to address Technical Debt
Experts suggest that tech debt is to be timely addressed in three scenarios:
- The first is when customer churn begins to creep upwards. This is a clear signal that end users are dissatisfied with the solution.
- If your brand image or reputation comes under fire due to lackluster performance or consistent malfunctioning, the debt must be repaid, yesterday.
- Provided the teams meet or work ahead of the mid-term product roadmap, the saved up time can be used to hone in on bug fixing. Though, mind you, the cost of addressing tech debt in the mid-term may turn out to be far greater than living with it until the end of the product development cycle. Instead, this is a great time to focus on project documentation and maintainability testing.
Takeaways
While technical debt might seem like a double-edged sword, it is probably because it is. Software modifications can prevent or create debt, while overengineering or prematurely optimizing software can introduce even more complications.
In order to avoid unwanted spend and time loss, everyone involved in IT projects will need to identify technical debt as a viable concept. And It is only by meticulously focusing on building requirements that align with key objectives, finding the right partners that implement the appropriate technology and defining achievable timeframes, project scope and budget that business owners will be armed against the negative effects of tech debt.
03 December 2019
WRITTEN BY
Pavel is Smart IT's Marketing Communication Manager. He oversees content creation and is in charge of the official Smart IT blog. Contact Pavel to learn about potential media and content collaborations. [email protected]
