Technical Debt – what can it mean for Startup

People related to digital industries often talk about tech debt, referring to it when having problems moving projects further. Yet not so many of them understand the full picture of this phenomenon and how it can impact not only startups but the whole digital sphere.

So what is it all about?

Definition.

Technical debt may sound more like a financial term, and it has similarities, even roots from it but actually more related to the tech and coding. Usually, it is referred to as a catchall that covers everything from bugs to legacy code, to missing documentation but it’s not perfectly right.

Originally,  the first one who made an on-point analogy for it was Ward Cunningham, one of 17 authors of the Agile Manifesto. He came up with it explaining to non-technical stakeholders at WyCash why resources needed to be budgeted for refactoring.

Later he described his metaphor like:
“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”

Can’t agree more with it.
Developers all the time dealing with this issue: the idea of developing a perfectly designed app/software/system, etc. Clean, thought out code allows future features and innovations to be easily implemented. However, in a business setting, time and resources often mean that developers don’t have the ability to produce clean, perfect code before delivering a product.

Simply put – the situation prioritizing meeting deadlines or budget over the quality of the product.

This is where technical debt starts its part. The concept recognizes a trade-off between perfect products and the short timelines often required for product delivery. While it can be useful to incur some debt, as with money matters, there’s a limit to how much debt you want to carry.

But is all that bad?

Not necessary. If you want a simple answer: It’s neither good nor bad, it’s debt. It’s neither good nor bad, it’s debt. And just like financial debt, there are several opinions around whether a technical debt is acceptable or not. It can be a tool to achieve short term goals as a part of a brilliant strategy and prioritizing. You can say it’s a business decisions –  risky, but they can be beneficial. Unfortunately, it’s not the only case when the technical dept appears. Thinking more about the reasoning behind the technical debt we can define a few types:

Planned Technical Debt – This type of technical debt occurs when the organization makes an informed decision to generate some technical debt with a full understanding of the consequences (risks and costs). Simply – caused by teams taking shortcuts to deliver prototypes or meet short deadlines. Skipping steps of the engineering process — such as refactoring, automated test coverage, peer review, error handling, and logging — saves time in the short run, but creates tech debt.

But even planned technical debt can easily get out of control as these decisions can accumulate quickly over time, it is imperative to maintain a record of them. So the technical debt will get addressed and paid down quicker. Otherwise, it will quickly be forgotten, potentially costing the organization big time in the long run.

Unintentional Technical Debt – This refers to unplanned technical debt that arises due to poor practices. It occurs when code is poorly engineered due to inexperience, incompetence, or lack of motivation. In a high-functioning team, these things will be caught through peer review of code and designs; but if a team is skimping on reviews (due to tight deadlines), tech debt can slip in unnoticed. Another source of unintentional tech debt is when code is written against misunderstood requirements.

But it’s only one scenario, often the business managers are pretty clueless about the consequences behind the tight deadlines and just pushing the process to move the launch date.

Unavoidable Technical Debt – This occurs due to changes in the business and the progress of technology over time that present better solutions. It typically arises when scope changes are requested mid-project, that result in an immediate cost such as adding a new feature to an existing design to better support mobile delivery. In short, technical debt is created when new business requirements make old code obsolete.

Acceptable or not? When to take debt.

Take it or not is a big decision to make and it’s important to actually make it rather than let it slip unnoticed. Working in a startup sphere we hearing a lot that “the main thing in startups is time to market” and that since you haven’t “proved your concept / validated your main business assumptions” yet it would be fine to incur in debt that you will pay eventually when your company is successful.

Overall sounds pretty appealing yet it’s not the whole story. Reid Hoffman (founder of LinkedIn) at some point said: “if you are not embarrassed by the first version of your product, you’ve launched too late”. And it’s quickly become an excuse for poor quality products. Tons of startups have launched and failed because of this approach. So considering taking the dept it’s mandatory to see the line exclusively for your business, that certain minimum quality required to make any product successful, even a small one.

This matches the concept of Minimum Lovable Product (in contrast to the MVP). The idea is that in order to get something fast, for it to be lovable, you should prefer sacrificing scope by ruthless prioritization.

So it’s safe to say that it’s acceptable if going smart with it. It’s a cooperative decision to make but with proper planning and dedicated team defining those quality lines, it’s possible to make it beneficial.