TECHNICAL DEBT*

*TECHNICAL DEBT* ​

NIRANJAN GIDWANI CERTIFIED INDEPENDENT DIRECTOR | BOARD MEMBER | ESG DIRECTOR | DIGITAL DIRECTOR | MEMBER UAE SUPERBRANDS COUNCIL | HBR ADVISORY COUNCIL During my recently done Digital Director’s Certification Program, I kept coming across this term “Technical debt”. This was something new and fascinating for me. So, I decided to do some more study to understand this phrase as well as its implications in today’s digitalized world. Technical debt, I realized, is the term used to describe the result of making decisions based on speed above everything else. These quick, real-time decisions can make or break software updates in today’s world which is going rapidly digital. This term “Technical debt” was coined by a software developer named Ward Cunningham, who first used the phrase in 1992. Since then, over time, the phrase has evolved. In current times, technical debt, also known as tech debt and code debt, usually occurs when development teams choose to write speedy code while building new features of any software development product. Since speed has become an essential and key parameter of business, these quick, real-time decisions can make or break software updates and organizations. Causes of technical debt include poor architecture, skipping steps in the software development process and failure to repeatedly and diligently test. Technical debt can also increase the risk of security vulnerabilities in payments and billing systems, putting sensitive customer data at risk. This can lead to data breaches, hefty regulatory fines, and reputational damage for the business. Imagine one has decided to construct a house of one’s own. Technical debt is like taking shortcuts or making quick fixes during the construction period, so as to meet a self-set deadline. Instead of using high-quality materials and following proper building guidelines and techniques, one compromises and uses cheaper or easier options to save time or money or both. Initially, these shortcuts appear to be very smart and convenient because they allow one to finish the house construction faster than the time the neighbor’s house took. Yet, over time, these compromises can cause problems. The low-quality materials may wear out faster, the electrical wiring may become tangled and hazardous, or the foundation and load bearing walls may start developing cracks. In the world of website development, technical debt is similar. It occurs when developers take shortcuts or make temporary fixes to meet deadlines or cut costs. These shortcuts may work initially, but they can lead to issues later on. The code can become difficult to understand or maintain, bugs may start appearing, or the website may become slower and less efficient. Put simply, technical debt is the labor cost associated with having to repeatedly rework previously implemented faulty code or software. It happens frequently and can quickly escalate to nightmarish levels for developers. Some estimates suggest that software engineers and technicians spend approximately 33% of their time dealing with issues which are technical debt related. And a survey conducted by Mckinsey indicated that 60% of CIOs felt that their organization’s technical debt had risen perceptibly over the past three years. If tech debt is on the rise in any organization, one may find staff spending more time doing maintenance and managing complex integrations instead of focusing on priorities that deliver business value. On digging deeper, one realizes that technical debt inevitably happens to every organization. Think of technical debt like taking out a loan to increase production capacity in a traditional goods manufacturing company. The loan is leveraged against the reduction in production time, and the interest is paid from future increased profits. The company is still profitable as it can save some money for the shareholders after paying back the debt. The fast pace of change in technology means that today’s cutting-edge technologies can quickly become obsolete and create a drag on an organization’s resources. Let’s focus for a moment on physical hardware. Hardware refresh cycles typically run 3 to 5 years, but sometimes equipment becomes obsolete well before the next investment cycle. An organization’s priorities may change during its lifespan, or some organizations may not have been clear on what they were trying to solve when they initially made the purchase, be it hardware or software. The consequences of increased technical debt are increased maintenance costs, reduced productivity, increased risk, frequent training and re-training, and moving a lot of key time away from looking at strategy and the way forward. More importantly, analysis of any kind of data becomes a nightmare. Just like in the world of finance, there is "good" debt and there is "bad" debt. Tech Debt started as a metaphor inspired by the finance industry. Just like financial debt, technical debt also accumulates interest. This means that the longer things remain unresolved, the more work will be required to fix those issues later. But is debt a problem? To buy a house, one gets a mortgage and pays monthly interest and the principal. This is considered positive because one could not afford a house on upfront payment. Leveraging debt allows one to achieve a goal. Starting a company requires initial funding. Entrepreneurs are praised when they raise money. The higher the better, but they are just borrowing money from investors expecting returns. Debt allows them to achieve a goal. Like a tool, it’s not a bad thing. That’s how the economy works. It’s the same for software development. To summarize, technical debt arises from shortcuts and compromises in software development and product acquisition. It also arises when companies lay down unrealistically short timelines. Problems start when the department which knows what’s going wrong are unwilling to disclose. If left unchecked, it can hinder progress and lead to maintenance challenges and drain development resources. However, to manage technical debt, like any other financial loan or debt, the key is to first acknowledge its existence, prioritize tasks, maintain good and honest practices, document all changes, and foster a culture of openness and improvement where periodic information is shared, not only about progress and success, but about what’s failing and needs to be rectified.