When you build an application, you want to build it the fastest way possible to release it and begin making a return on your investment. You might build a minimum viable product (MVP) to test the market before investing in a more robust application. Focusing on speed of development is good for the initial launch, but building an application that isn't scalable or flexible leads to technical debt. Technical debt is costly, causes developers to constantly chase bugs, and often leads to developer burnout.
What Is Technical Debt?
The best way to describe technical debt is by comparing it to standard debt with a loan and interest. When you take out a loan, your payments include paying off interest and a small portion of the principal. If you only make payments that cover the interest, you never pay down the principal. The result is that you constantly make payments without reducing your actual debt. Payments will never end, and you'll always "chase" your debt.
Technical debt works similarly, but it involves software development and bugs. Bug fixes are expected in software development, but the underlying problem should also be remediated along with fixing the bug. In development, if software engineers constantly chase bugs and fix them but never remediate the underlying issue, the organization accumulates technical debt without ever reducing it. It's a phenomenon that causes constant emergency fixes, and developers soon get burned out. For the organization, developers never have free time to build new features and improve the application because they are always fixing bugs instead.
In an enterprise environment, accumulated technical debt costs money. When bugs affect productivity or user experiences, accumulated technical debt may be to blame. It's an unavoidable issue in small amounts, so some technical debt should be expected. Developer churn also costs money. Training, onboarding, and the time to offboard and hire another developer are unnecessary costs associated with technical debt.
Real-World Examples of Technical Debt
Most developers have experienced technical debt, a common pitfall for any organization. For example, suppose you ask developers to build a website for a new product release. Developers work with an out-of-the-box solution such as WordPress or Shopify to reduce development time. These solutions give you a quick solution, but now you need features added to the site. If developers aren't familiar with customizing WordPress and Shopify, they now need to take time to learn the platform and build features that could be buggy due to unfamiliarity with the product.
Another example common in enterprise development involves feature requests and programming languages. Developers often want to work with the latest trendy language. It's great for improving developer skills, but it can cause technical debt when developers build software with unfamiliar languages. They can fall into common traps that create problems in the future.
Poor quality assurance (QA) and testing strategies also cause technical debt. All aspects of any software should be tested thoroughly before being deployed, but some development teams struggle with good strategies. Human and automated testing should be used to ensure that bugs aren't released to production software.
These examples are simple, but even simple mistakes can cause enterprise businesses to accumulate massive technical debt that often results in years of bug-chasing and monetary costs. At some point, it's critical for the stability of software to reduce technical debt.
Chipping Away at Technical Debt Strategically
Once you know that your technical debt is costing the organization too much, you can strategically eliminate it. You can't reduce it by 100%, but you can take the necessary steps to reduce it so that developers can focus on improving features and generating a better return on your investment.
The first step is identifying technical debt, auditing your software, and determining priorities. For example, if a critical application has multiple bugs impacting revenue, it might be good to start chipping away at technical debt to limit negative effects on revenue. In other strategies, you might want to reduce technical debt by focusing on applications with the smallest amount of debt to get them out of the way. This strategy also gives developers a sense of accomplishment, which helps with morale.
The biggest factor in more streamlined development is automation. Automation requires development time upfront, but it eventually reduces time and potential mistakes. Developers should automate any repeatable processes. For example, deploying applications to a virtual machine in staging with the same configurations can be automated. A good automated script will deploy the application, resources, and configurations within seconds rather than manually. With automation, developers have more time refactoring code to reduce other technical debt from bugs. It also reduces the chance for bugs, misconfigurations, or mistakes during deployment.
Some technical debt requires refactoring code, which often takes more time than scripting. A good target strategy is to spend 20% of your developer time reducing technical debt while developers also deal with bug fixes. For example, if a software module has a known bug that appears frequently, developers should take time to determine how to stop the bug from reappearing. This might require rewriting code, changing the database, or updating infrastructure. Developers should spend time determining the best way to remove the technical debt, make a plan, and then do the work. The strategy takes effort from the entire team, but the result is less bug-chasing.
Conclusion
Reducing technical debt can take months in an enterprise environment. The important step is making a plan so everyone has a goal. An independent code review is an excellent way to identify, log and prioritize the issues that exist as well as the best approach for resolving them. After months of work, the enterprise will see monetary improvements, more developer time for feature requests, and a better software development lifecycle. Stakeholders and software customers will be more satisfied with your product, and fewer bugs build trust with users.
To avoid technical debt in the future, take time to fully design a scalable software product from the beginning (or work with a reputable software development partner that will). Don't skip the design phase of development (prototyping), and make a clear plan that includes user features, potential future functionality, and infrastructure to support a spike in new users. By planning ahead, you can avoid technical debt and the cost associated with pitfalls.
Tagged as: Technology, Legacy Software, Custom Software
About the Author:
As co-owner of custom software development company, Envative, David has been immersed in Internet based application design & development for the past 30 years – with total development experience exceeding 30 years. He has held positions ranging from senior developer, systems manager, IT manager and technical consultant for a range of businesses across the country. David’s strength comes from a deep knowledge of technologies, design, project management skills and his aptitude for applying logical solutions to complex issues.