Technical debt: Ally or adversary of Scalability?
When working on a team developing digital products, sometimes reality, business’ requirements, time and deadlines, code quality, and context’s demands do not go on the same path. Therefore, reconciling some aspects with others can be a challenge difficult to solve. Difficult, yet not impossible.
On the one hand, the term ‘Technical debt’ refers to the flaw, more or less known, that a software product has. It may occur because of bad coding, deficient deployment processes, inadequate decisions about architectures, outdated software, among other reasons. That flaw attacks or generates problems in the product’s development or lifecycle. On the other hand, ‘Scalability’ alludes to the propriety a software product has that allows it to grow in reference to required changes to the software product or in reference to business growing needs (for example: if the amount of users increases, the number of requests rises, and the software product needs more computational power). Scalability may apply to software modules —the code written— or to infrastructure —in which software modules are executed—. It is important to develop scalable software if we pursue that software products survive, grow, and succeed. When developing a new software product we generally have two antagonists in conflict: the desire of launching a product to the market soon and generating value to the business, and the desire of doing everything with the highest possible quality, which is one of the most important requirements to have scalable software products. A software product that aims to be successful must be able to generate value in a timely manner and to grow under users’ requirements. Unfortunately, this is not easy because generating value in a timely manner usually produces Technical debt, the enemy of Scalability. So, how can we solve this conflict?
The key to make Technical debt and Scalability coexist and specially to prevent Technical debt to damage Scalability is to manage Technical debt. We should avoid reckless and unintentional Technical Debt. Otherwise, we should generate known Technical debt the team is aware of. “I consider documenting Technical debt in tools accessible to the whole team is useful, as it helps everyone to be conscious of its existence and the less experienced in the team to understand its importance”, explains Emanuel Friedrich, Full Stack Engineer in our team. Some companies may opt for having specialized teams dedicated to look after product’s scalability, which is an excellent idea though not always budget affordable. Dedicating time and space to sprints to treat Technical debt being generated can be the choice of other teams that prefer to tackle Technical debt faster, before it begins to be problematic.
The first step to leave a manageable Technical debt is to test the software product in the best possible way, so that Technical debt is increasingly more related to scalability problems and not to bug fixing. The more test coverage our product has, less likely it will fail unexpectedly, with the consequent less possibility that bugs are detected by final users. “… you need to (…) hire QA staff that can inject testing rigor into your release process. Regression testing, backward compatibility, UI, performance testing should all be part of your QA process before a product is signed off for release”, explains Shirin Dehgran (2021).
It is possible to have Technical debt with the purpose of delivering value in a timely manner without disregarding Scalability as long as the team knows it, documents it, understands its importance and treats it on time. How? Here are five (5) keys we would like to share with:
- Having good tests’ coverage.
- Documenting Technical debt.
- Being conscious of the existence and importance of Technical debt.
- Planning in advance when to treat Technical debt and an approach of how to do it, which provides more certainty of its implications, possible solutions, and impacts when doing it.
- Understanding the quality as an ally of Scalability.
Leadership becomes extremely important to achieve all this, as leaders should understand and be able to transmit the importance of Technical debt and the problems it brings to Scalability. Most experienced leaders and developers should convey to the rest of the team where the Technical debt is and how it impacts the product’s development and survival. The term comes from the financial sector; as well as when we go to the bank to request a loan out of necessity to invest in a business or to build a house, Technical debt is usually a necessity at early stages of software development. However, as well as the bank’s loan, the debt that is not being paid off or treated, generates more interests. Treating Technical debt that has “generated interests” tends to demand more effort and leads to an unavoidable discomfort and unhappiness in the team, that has to dedicate more to maintenance than to generate new features.
Probably, some Technical debt is inevitable, but it does not necessarily have to generate problems for the business and dissatisfaction in the team treating it, always taking into consideration that it was generated with a justifiable purpose. In similar words, Dehgan says: “Technical debt is the reality of every scale-up CEO. Ignoring it is not an option, nor is stopping innovation. The only way to tackle this is head on by including the time and resource cost of this in your plans. In short, get on top of your technical debt before it gets on top of your business” (2021). In general, Technical debt related to value generation is more tolerated by the team than Technical debt that appears because of carelessness and that is not intentional. Value generation and its promotion —that is to say, that product teams highlight its value, its importance for the company, as well as users’ and clients’ appreciation— can maintain the team’s motivation in spite of the technical debt they have to deal with. What is more, teams may look for more resources to treat Technical debt in case it is necessary and to support the expected growth, favoring all Scalability’s processes. Happy teams and satisfied customers or users are a perfect combination for successful digital products.
Dehghan, S. (2021, march 25). The Software Scale-up Dilemma: Technical Debt or New Features? Frog Capital. https://frogcapital.com/scale-up/the-software-scale-up-dilemma-technical-debt-or-new-features/