Build Now, Fix Later? Understanding Technical Debt…
Kartik Menon
Sr. Product Manager, The CENTA for Teachers App | Helping 1.7 million teachers become better I 40 under 40 BusinessWorld (Education) I Writer@UX Collective I Love all things Product
“Why is this feature going to take so long? This is a rather straightforward ask right?”
“Well yes, but we need to fix a few things first! Remember we had spoken about the patchwork we did in the last release?”
As folks building a digital product, how often have we found ourselves engaging in a similar discourse with our development teams? And honestly, it is not always their fault, at least not intentionally…
Build Now, Fix Later?
This is the day and age of “Buy Now Pay Later (BNPL)” right? You can practically buy anything even if you don’t have the money and pay for it later. And while short-term finance has helped you buy what you wanted, the niggling feeling of paying back the money borrowed (often with high interest) keeps bothering you. And in the unfortunate circumstance of you not paying back the money on time, the interest just goes on compounding and you ultimately end up paying a very high price in the bargain. Technical Debt, very often, works on the same principle.
While building products, we are often compelled to “hit the market first” because “time is of the essence”. And while this is a very valid push to have, speedy delivery often comes at the cost of optimal code. Development teams often end up making choices while expediting a functionality but these choices result in extra effort down the line which then needs to be factored in during future releases. So the governing principle is pretty much along the lines of — “We will build this now, ship out the feature, and come back and fix it later!”.
To put it simply, Technical Debt gets created when developers use shortcuts to ship out features faster but at the cost of a codebase which is extremely hard to maintain down the road. And suppose the compromised pieces of code are not rewritten and fixed promptly, they will come back to haunt not just the developers but in many cases trigger a whole chain reaction that affects core business operations and verticals.
This term was originally coined by Ward Cunningham (also one of the authors of the Agile Manifesto) while explaining to stakeholders at WyCash why budgets were important to refactor and maintain the code.
Technical Debt in Action
Southwest Airlines holiday travel meltdown — In December 2022, Southwest Airlines, a major U.S. airline, and the third largest by domestic passenger volume, canceled more flights than usual, including more than 60% of its flights on two days. While the primary reason for these cancellations was a North American winter storm (debatable), it is interesting to note that while all airlines were affected, Southwest ended up cancelling a disproportionately higher number of flights. Reason — an outdated flight scheduling model and internal management system (technical debt accrued over years). Experts state that at the time of the crisis, Southwest’s systems were at least 2 decades behind those of their rivals. Now if processes had been put in place to overhaul the systems at regular intervals (or even in a single go) — there would have been a cost associated with it but that cost would have nowhere been near the one they incurred — a $140M fine from the U.S. Department of Transportation and the agreement to establish a $90B compensation fund for future delays.
The Y2K Problem — Developers in the 1960s and 70s had taken a conscious call to store year data in 2 digits (instead of 4 — so 75 instead of 1975 or 00 instead of 1900). The reason was to save on memory (which was expensive at that time). Despite memory prices going down each year, little to no efforts were made to change the way this data was stored. Businesses and Governments continued to follow this route and it became embedded in lots of business processes. Now, as the new millennium came on the horizon, everyone realized that the date calculations were going to fail at scale, and thus began an unprecedented scale of scampering to sort things out. At a worldwide level, it is estimated that a little over 300 billion dollars (taking inflation into account) were spent on Y2K remediation measures — surely if pre-emptive measures were taken to refactor this technical debt, this cost could have been spared!
Is Technical Debt always bad?
Well, not always. Product Managers and Development Teams often work under the “ship or sink” pressure — which means that unless you are building and shipping fast, you are likely to fall behind competition. In scenarios like this, technical debt is a useful tool for teams to ship features fast (with the promise of getting back to the less-than-optimal lines of code to fix them). This can help businesses respond to opportunities in a more time-bound manner.
However, the real issues come up when the technical debts get compounded. This could happen in two ways — a) if teams are not provided sufficient time in each sprint to progressively fix the patch works that were done in the previous release and b) if the patch works and quick fixes were not properly documented. Scenario b) will become even worse if those who made the quick fixes transition out of the team — so the ones who replace them will have no clue as to what was done!
Any new build/ enhancement of a product that is sitting on top of a pile of compounded technical debt is a disaster waiting to happen — unintended conflicts can occur anytime thereby severely debilitating the chances of improvements or innovations.
领英推荐
Types of Technical Debt
Primarily, there are two categories of technical debt — Intentional and Unintentional.
Intentional Technical Debts are byproducts of conscious business calls that have been taken. As long as teams document the optimizations done and budget enough time for refactoring the same, things will be under control. Eg. If an app requires a survey feature to be built immediately, the PM may take a call to integrate/ add an external survey tool into the app (which stores the survey results in an external database). As long as the team comes back, builds in a survey tool inside the app, and migrates all the past survey data to the main DB, the intended technical debt would have served its purpose.
Unintentional Technical Debts are the results of changes that are driven by expediency but without intentions or plans to come back and refactor the patch-ups done. Unintentional Technical Debts might also be caused due to poor adherence to development standards or even truncated/ lack of proper testing. There might also be debts that come up if there is a lack of proper documentation (whereby new joins in the team might not understand the code if the dependencies are not properly documented).
Warning bells are ringing!
So how does one get signs of a compounding technical debt? From personal experience, in case you are seeing one or more of the following happening in your product/ development timelines, it might be a good idea to deep dive on priority to check if you have started to compound on technical debt:
Can Technical Debt be measured?
Yes, there are different ways to measure technical debt. The most popular way to compute it is the Technical Debt Ratio/ Technical Debt Formula:
(Refactoring Cost/ Development Cost)*100% = Technical Debt
The idea is to compare the cost of what it would take to fix the problem against the total cost to build the product. The ideal TDR ratio, as per experts, is 5% — significantly higher ratios might indicate a difficult spell on the product and development front.
Dealing with Technical Debt
Once the signs of technical debt along with the quantum have been established, it is important to start on the efforts to pay off the debt! These efforts will not only involve better documentation, putting in place a set of standard coding norms to be followed but also going all out on the front of establishing proper KT sessions for newer developers in the team.
There will need to be made changes/ enhancements on the testing front as well — with efforts on Shift Left Testing (ensuring that testing starts at an earlier stage and continues through the development process) and Shift Right Testing (testing immediately after the production release has happened so that any pending bugs are identified on priority) to be intensified.
Additionally, all the stakeholders involved (particularly on the product and business front) should review the priorities and move around items to create enough breathing space for the developers to refactor and fix the patch-ups done.
Needless to say, managing technical debt needs to become a part of every organization’s formal processes and team culture.
A little bit about myself — I am one of the founding team members of Centre for Teacher Accreditation (CENTA). Over the last 8 years, I have donned a bunch of different hats cutting across verticals. Despite coming from a Liberal Studies background (or maybe that is the reason!), technology fascinated me quite early in my career and I have always loved to explore how it can be leveraged to solve problems at scale. In my current role, I am the Senior Product Manager of the CENTA App — the largest platform for teachers in India (and one of the largest globally) — we have 1.4 million teachers from over100 countries on the platform who frequent it to access both free and paid learning resources and professional development content…