The Technical Debt

The Technical Debt is the unfinished code. Photo by Markus Spiske on Unsplash

There are multiple challenges that all organizations, regardless of their size, would face at some point in their existence. Among the most common ones we can find: The Technical Debt (TD) where often -engineers will know- there’s the right way to do something, and the quick way to do it, as Dag said [1].

This situation is far more frequent when a new solution is being developed due to budget restrictions and deadlines. The solution should be delivered to the market as soon as possible in order to attract potential clients and gain feedback. However, the cost of implementing these “quick wins” is like borrowing money, sooner or later, it has to be "refactored", to be paid

TD is not necessarily the fruit of mistakes nor the result of constant changes through time. These are only examples of it. However, TD can also be a conscious, voluntary decision and -in some circumstances- a correct one, especially, if you are designing a proof-of-concept or a prototype, but it’s important to document all these decisions in order to create the proper prioritizations of tasks, technologies, requirements, among others when the refactoring time comes.

Risks of the TD.

TD can be considered as a monetary debt since it involves additional work from the programming team, which in turn involves salaries, time, effort, and resources in order to be repaid while the code is being refactored. While the TD is being taken, an impact analysis should be performed. This analysis should take into consideration [2]:

• The business value of the component.
• History, age, and future decommissioning of the component.
• The probability of getting a negative impact due to the assumption of the TD.

In order to do a proper impact analysis of the TD, we could use Table 1.

Technical Debt item attribute	Detail, Rational
Type of impact	Activities and abilities hurt
Amount of impact	Size of the impact
Duration and periodicity of the impact	What will happen once or will rear?
Timing of the impact	Is it going to impact fast?
The age of the TD item	Is it legacy or added before?
Is it intentional or not?	Involuntary might involve coaching or training
Refactoring costs	Plan repayments activities
Dependencies with other items	Shat be added to another items?

TABLE 1. ASPECTS TO TAKE INTO CONSIDERATION FOR TD. [2]

Types of TD.

The TD can be split into three main types and there are some solutions that could be used to address them effectively [1].

1.   Deliberate TD. In many cases, the teams are going to need to make a decision between a quick fix, like reusing a module that was designed for a different solution, or develops the proper implementation that might involve additional approvals and extra-work from other teams.

This kind of problems are faced when a product needs to be delivered to production as soon as possible.

How to address it? This kind of change should be documented and reviewed after a certain period of time. If there is no visible issue, it can be forgotten causing further problems in the system and leading to the need for a full re-engineering process.

2.  Accidental/outdated design. Over time, systems' changes and requirements would vary; therefore, a solution that would solve all problems is difficult to manufacture. It’s important to balance a quick delivery and the simplicity of the solutions. Internal and well-documented solutions could be easier to refactor, but in certain cases, if the wrong solutions were considered, they might involve massive changes.

How to address it? Team/tech leads should consider a specific amount of time for discussing the possible solutions, prior to the acceptance of TD, in order to minimize the impact it.

3.     Bit rot. This one would happen over time, especially when new features are added to any solution and can be exemplified in Figure 1.

Figure 1. The TD metaphor treats the cruft as a debt. [3]

The system that is stable is represented with blue color and the green color represents the TD. Also, the triangles or crufts represent the features that would be added. As in any system, these ones could have smaller or wider technical debts, some of them would come from copy-paste and cargo-cult programming.

How to address it? this one is the most delicate and more frequent in our times since there are multiple sources where programmers could collect new pieces of code: StackOverflow, GitHub, Forums, legacy systems, among others. The best idea is to implement good practices inside the organization and a robust software development life-cycle that includes peer-review or "code review", in a more general sense. This would clean new additions to the code and avoid bad or unnecessary code injected into the internal systems.

Reasons for the TD.

There are multiple reasons why an organization could embrace TD(s), some of the most common ones are [4]:

• Last-minute changes or omissions of functionality.
• Incompetent technical leadership and bad systems architecture.
• Efforts to minimize startup capital.
• Outsourced software engineering.
• Ignoring industry standards.
• Building tightly code.
• The non-existent test suite, continuous integration, and deployment.

Theoretical business case.

After, an introduction connected to the TD, let’s suppose a theoretical business case that would incur a deliberate TD.

The European Union approved some funds to support a small Spanish project called: “Proyecto Aurora”. These funds are coming from Horizon 2020 and the startup should provide the first results after 6 months.

This project is for improving the quality of life of the citizens living in the jungles of Panama. The startup should develop a prototype of their apps (iOS and Android), website, hire developers, pay bills, and rent. Their budget is restricted to €60,000 that they should retrieve if they are not able to show the running prototype. After the group of developers was recruited, the leaders discussed with the team what were their expectations and the limitations they had to build the website and the app. The developers provided two possibilities:

1. Development of the apps and the website with .NET Core, Azure, SQL Server, and Xamarin.Forms in a period of time between 6 to 12 months. Supervised by a customized version of Scrum (Agile Methodology).
2. Development of the apps and website with WordPress and Bubble.is in a period of 3 months (quick solution, but not recommended because it would create massive dependencies on 3rd party solutions and a high TD in the short term).

The leaders of the startup analyzed their current situation since they spent approximately two months hiring the developers and now, they were running out of time with only four months left to show the prototype to the EU representatives. Therefore, they decided to take the risk and went for the "quick-win" option: #2 - WordPress and Bubble.is.

After several tests and close to the deadline, the first preview was finished. The prototype was a success, but over the following months, many new features have to be added to their project, including some possible implementations of Machine Learning in Python in order to identify the most vulnerable locations in the jungle. All these changes incurred massive payments and refactoring of the code since neither Bubble.is nor WordPress were designed for this specific project, bringing the startup to negative numbers in a short period of time and searching for additional funds.

The previous example involved a deliberate TD because; as it was explained at the beginning of the essay, “often, engineers will know there’s the right way to do something, and the quick way.”

Was it worth it? In a certain way, it can be justified by the limited budget and the deadline to present the results. This is just a common scenario that many new products or projects face after the first round of investments.

Could it have been improved? Probably. A possible solution: the leaders could have gone in deeper talks with the developers’ team and combine the best of both solutions to reach an alternative. One solution could be: to keep WordPress as the technology for the website while Xamarin.Forms for the development of both Apps since WordPress is based on PHP and MySQL could have supported further developments of some web services; also, the implementation of an Agile Methodology with Storyboards would have helped the team to identify proper business cases to develop the MVP of their business.

Conclusions.

The TD can affect any organization regardless of its size, years in the market, or experience. 

There are multiple types of TD, i.e., Deliberate, accidental/outdated design, and bit rot, and each of them should be treated carefully and documented every time to not be forgotten over the years.

TD is not necessarily a bad decision because it can help to launch a new service in a shorter period of time to the market, but there should be a proper plan for repaying the debt (refactoring of the code).

Bibliography.

[1]	FirstMark, "There are 3 main types of technical debt. Here’s how to manage them.," 01 25 2018. [Online]. Available: https://hackernoon.com/there-are-3-main-types-of-technical-debt-heres-how-to-manage-them-4a3328a4c50c. [Accessed 09 06 2019].
[2]	J.-L. Letouzey and D. Whelan, "Introduction to the Technical Debt Concept," [Online]. Available: https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf. [Accessed 09 06 2019].
[3]	M. Fowler, "Technical Debt," 21 05 2019. [Online]. Available: https://martinfowler.com/bliki/TechnicalDebt.html. [Accessed 09 06 2019].
[4]	RMB FOUNDeRY, "Extreme programming practices that mitigate Technical Debt," 03 07 2017. [Online]. Available: https://www.foundery.co.za/blog/extreme-programming-practices-that-mitigate-technical-debt/#. [Accessed 09 06 2019].