Technical debt gets a bad rap. Engineers and technologists tend to speak of it as something to be avoided – a liability that accrues from mistakes, poor planning or sloppy coding.
Nobody wants those problems, but it’s not fair to say that all technical debt is bad. In fact, the right kind of technical debt helps ensure timely delivery and makes products vastly more configurable down the line. When technical debt is recorded, tracked and paid back on time, it makes for stronger products. And as we’ve learned at Zipari, it can even be attractive to investors.
The right kind of technical debt
One of the hard-and-fast realities is that whenever you build a product with code, you accumulate debt. Every product-development process has constraints – time, resources, what’s known about how users will use the product. Those constraints cause engineers to make compromises as they write the code, which in turn produces technical debt.
A finished product with no technical debt would be, by definition, perfect – in every line of code, every functionality, every use case. No such product exists, because it’s simply impossible.
4 ways to minimise and manage technical debt
Building up this sort of debt is normal and perhaps required but it’s key to keep it under control
Given that every product has some debt, there should be no reason to pretend otherwise. And yet engineers quite often do just that, declaring there is no more work to be done after a product’s completion.
This oversight isn’t entirely their fault. Sometimes product teams and the executives managing engineers are quick to view technical debt as a sign that the code writers cut corners because they’re lazy or weren’t talented enough to solve the problems they encountered. So, engineers hide their debt, perhaps making notes to themselves, hoping nobody will notice and they can go back and fix it later.
However it’s created, the hidden technical debt in those products is eventually revealed – bugs emerge, the product breaks, customers complain.
Bringing technical debt into the open
At Zipari, we take the opposite approach: we bring debt out into the open by requiring engineers to record it as they go. As long as they meet our customer’s most critical requirements, they are empowered to build technical debt into the product, record it and keep moving toward their deadlines. That helps ensure we get products into production on time and enables us to pay our debts back based on our own schedule, so we can address the most important weaknesses first.
Requiring engineers to record their debt tells them that our leadership understands writing code against a deadline means they will have to cut a few corners along the way. It shows that delivering on time is paramount – that we don’t want them to waste time endlessly refactoring, groping for solutions to problems that could cause us to miss our deadline.
Could understanding the technical debt hold the key to improving cyber security?
Above all, it communicates to the engineers that technical debt isn’t bad. If we meet our customer’s core requirements and deliver when we said we would, we can always go back and manage the debt after we’re in production.
As they record their debt, we also ask our engineers to score it based on their assessment of its importance to the overall functionality. After we deliver the product, the team can assess all the debt we’ve accumulated and make decisions about which areas to address first and determine what resources we’ll need to pay that debt back. We know where we cut corners and which problems we still need to solve, so we’re not constantly reacting when code leaks or bugs emerge.
More configurable code
Bringing technical debt into the open also makes it easier to configure our products after they’re in production. Any engineer will tell you that of the hardest parts of building a new product is configuring it correctly, partly because it’s impossible to know exactly how the customer will use it.
Because we revisit the debt after the product has already been in production, it gives us insights into how the customer uses the product in a live setting. Therefore, we end up with better configuration than we’d have achieved by guessing at our client’s needs during the build-out.
This approach to technical debt appeals to engineers because it recognizes the realities they’re dealing with and rejects the pretense that they’re building flawless products. We’ve also found that it appeals to technology investors, who know the realities of technical debt as well as anybody.
Nearshore software development: how multidisciplinary teams increase the odds of success
Before they deploy their capital in any enterprise, investors identify and assess its technical debt. In many cases, that due diligence requires them to comb through the code, looking for the bugs and the corners that have been cut.
Recording all your technical debt saves potential investors loads of time. When our leadership talks to investors, they’re able to hand them a spreadsheet showing all our technical debt — it’s not just efficiency, it demonstrates that we value meeting deadlines, that we’re in control of our processes and that we are far less likely to get crushed by unexpected tech-debt breakdowns we didn’t see coming.
And at the end of the day, it shows that we’re realists. We know that no product is perfect, but we have a plan for getting a little closer at every step.
Written by Jyoti Mokal, VP of Zipari
