In this post, I would like to discuss something developers face daily when deciding on the features or architecture of an application. Let us talk about technical debt!
What is Technical Debt?
According to Filipova and Vilao (2018), technical debt consists of all the issues that can lead to refactoring the code of an application. But for Ward Cunningham, who coined the term, it refers to how the quality of the software, in the long run, is affected by choosing the short-term development speed (Mohanty et al., 2016). I define technical debt as any decision made by the team not following best practices that make the system difficult to maintain. These technical decisions could add more work to the project in the long run (Lilienthal, 2019).
How Technical Debt Happens
Technical debt could happen with every decision made by the team. For instance, a team might decide on a hybrid app assuming that they could save development time. However, they might end up with technical debt in the long run if the team needs to rewrite the entire application in the future. Just look at some applications that were created in PhoneGap years ago. Developers that used this service needed to build the applications from scratch once they saw that the service was shutting down.
Look at all those apps created with AngularJS that needed to be rewritten after it was announced that AngularJS was replaced by Angular, and it was a completely new framework with no path to upgrade. This is considered technical debt because the decision made by developers to use the framework as it was easier for them to develop the apps, also compromised the future of their code.
Another reason why technical debt happens is by trying to be first in the market or by trying to react quickly to competitors with similar features. We live in a competitive world and whoever goes to market first could find a blue ocean and create a legal monopoly in the market. Thus, it is understandable that a development team does not have the time to create the “perfect” application. But there should be a balance because the same application could be killed by technical debt if this debt is not paid on time. Always consider that shortcuts that we take catch up with us sooner than we planned.
Technical Debt Could Kill Your Project
I know of applications that were killed by technical debt. The projects were so deep into the rabbit hole, that only a rewrite of the entire applications was possible. One of the projects depended on external extensions so they could deliver the product as soon as possible. However, after several months, the same “useful” extensions were no longer maintained by their developers which brought a big problem to the product team because they had to find alternatives or a way to maintain extensions that they didn’t know anything about other than using them as customers. Thus, instead of supporting the application, developers need to learn and maintain the extensions that they installed instead of dedicating efforts to the actual application.
What was considered a good idea, later turned out to be a very bad decision because the product team inherited this code that followed different coding standards and was created by developers with different skill levels in the open-source community. The open-source community is great but developers that are not paid to be full-time contributors to the open-source software need to find a way to get paid; if not they will lose interest if these extensions don’t align with their priorities.
References
- Filipova, O., & Vilao, R. (2018). Software Development from A to Z: A Deep Dive into all the Roles Involved in the Creation of Software. Apress, New York, Ny.
- Lilienthal, C. (2019). Sustainable Software Architecture. dpunkt.verlag.
- Mohanty, H., Mohanty, J. R., & Balakrishnan, A. (2016). Trends in Software Testing. Springer.
