Software development is a highly volatile industry where new project management tools, frameworks, and methodologies come and go as quickly as we can come up with new buzzwords.
Some methods, like lean development, make more sense than others, but not a single new method, trick, or technique can argue with the fact that “the quality of work is constrained by the project's budget, deadlines, and scope.”
Sometimes, we can bend the game rules to a degree, but breaking them entirely is never an option.
What is technical debt?
Technical debt is the price a company will pay later for choosing a simpler, faster, yet less reliable option today. Any compromise you make to release products or features faster in the present will accumulate a greater volume of work to do in the future.
Moreover, technical debt—just like any other form of debt—accumulates interest unless carefully taken care of.
The so-called interest makes new feature releases more expensive and less stable. Your team will be wasting time dealing with compatibility issues and bug fixes. They won’t be able to focus on the actual development of new functions.
Straight to the point: Immense technical debt inflates software maintenance costs to the point where supporting the original solution is no longer an option.
Why do projects fall victim to technical debt?
Two primary reasons companies tend to tie themselves in technical debt: Time & Money
Any business, big or small, needs new features. Fast! So there’s no wonder borrowing time and financial resources seems like a legitimate solution.
Most startups are underfunded. Apart from the competitive and volatile markets, the lack of resources is often cited as the primary reason leading to product failure. In other words, two out of the three sides of the iron triangle are off the table before development even begins.
And yet, both young entrepreneurs and seasoned veterans of the investment scene take the risk. Everybody wants to be in the 1% of successful small companies that make it to the top.
Few truly care about technical debt because technical debt is not the main factor determining whether a startup will promptly raise investment. These factors are time to market, competition, and the growing user base.
Then there are enterprises: the gargantuan players that are quite slow when it comes to adopting change. These companies have spent years and decades perfecting business processes that are tailored to maximize profit and ROI.
More often than not, these companies are run by people with a business-first mindset without a strong background in IT. Sadly, they see development as a bottomless pit of unnecessary investment.
Why waste $100K on refactoring if the product works as is?
Why invest in experienced coders when middle or junior engineers are speaking the same language?
Why waste time designing architecture when the market demands new functionality?
These and similar questions trouble the minds of decision-makers and product owners with a business background.
The simplest solution is not always the best one
Building a product for 100 users without a solid “foundation” will work just fine in the present, but will fail once the user base grows to 1000 users. The absence of a reliable development methodology is easily missable at first. But then things can go sourly wrong.
Given the circumstances and the continuous time-budget constraints, many companies and vendors fall victim to saving on all the wrong things:
- Software architecture
- Infrastructure planning
- Knowledge management
Think about this:
- What will happen on a project without documentation when new team members are onboarded?
- What will happen to your website’s or app’s live version when a new feature is introduced without being tested for compatibility?
- How can you be certain of the overall quality of your code if it has not been reviewed?
The implications of being in debt to your own product
Large technical debt affects the bottom line
What do you do when a website you’re trying to access fails to load quickly? The odds are you’ll leave to look for a different website. In fact, 53% of mobile users will leave if a website fails to load within 3 seconds.
The same can be said about any product that continuously experiences downtime due to the system’s painful introduction of new features.
Services that rely on impulse sales are probably the best example. Especially in the transportation industry, where customers interact with the taxi service continuously, such downtimes create inconveniences in the established routines. People run late, annoyed by lagging applications, and taxi drivers lose their profits. Moreover, transportation is a competitive market, where competitors bombard users with promo codes and offer a service that always works. Over time, each downtime shrinks the customer base.
Similarly, large projects will lose their client base over time if they continuously expose their clients to bugs and downtime.
Why technical debts lead to “The big rewrite”?
If the system is deep in technical debt, there will come a time when sustaining it is no longer effective and even counterproductive.
If the risk of implementing fixes or new features is too great (for example, a bank or a financial system cannot afford downtime), the product needs to be remade from scratch.
This new system is called an Antipattern: The Big Rewrite. It’s essentially the same product built from the ground up, but this time with appropriate procedures and processes in mind. If all goes well, the users are then migrated to the new version of the product in batches.
The big rewrite may sound like a reasonable solution to the challenges of technical debt, but only at first glance. In reality, you will need to develop and maintain two projects instead of one until the entire user base has migrated to the second iteration of your product.
Then there’s the reason why the antipattern has earned its name: more often than not, a newly rewritten system never gets to production as it can’t keep up with the features developers are introducing into the original system.
Alas, the only alternative is a broken solution and the eventual loss of the entire user base.
Ways of fixing projects stuck in technical debt
Are there alternatives to introducing an antipattern? Sometimes yes, and sometimes no. The availability of solutions will depend on the severity of the situation you have ended up in.
In the best-case scenario, you are working with the original team that has been working on the project since day 1.
Steps to take:
- Working closely with the team. Getting everything from their heads into cohesive documentation.
- Analysis of the issue tracker: info in the ticket description, labels, and assignees can shed much-needed light on the state of your project as a whole.
- Implementing change through tests. This means that the tests are written before coding. That’s how you ensure the system stays intact and is not affected by the implementation of fixes.
This scenario usually occurs when a business has gone through one or more development teams over the course of the development cycle.
Steps to take:
- Technical archaeology: an attempt to understand and document the system.
- Analysis of the issue tracker.
- Introduction of fixes and issues through testing.
How to manage technical debt on a budget
What about operating on a budget? Can a development team deliver a successful project without investing an arm and a leg?
- If you are working on an MVP, and ONLY if you are willing to re-develop it from scratch after raising additional funds, you can skip some of the most time-consuming processes in favor of time-to-market delivery.
- Alternatively, you can go back to the Iron Triangle. Taking the price side away, you will be left with time and quality. This means that you can develop a fantastic product without skipping any important business or project management processes. Prepare yourself for long-term estimates. Unfortunately, this approach is the only viable option when it comes to creating scalable, future-proof projects.
- Lastly, if you had a viable reason to skip one or several development processes, create a preemptive ticket to fix the issue in advance and label it “technical debt.” This way, you will always keep tabs on the bigger picture without borrowing too much, or at least you’ll help your future self with sorting out the mess. In either case, technical debt is much easier to cope with if it’s well-documented.