You have a successful business for the last 10 years. Your sales numbers have been historically great and have grown consistently in the earlier part of the decade. Your customers are asking for new features in your product or service offering. Sales teams funnel those requests through your customer experience or product management to your IT, technology or software development team. Your development lead gives you a timeline to deliver those features which is unacceptable to both sales and your customers. You are at risk of losing your customers, some may even cite your competitors who have those features in their products or offer their services already. The executive team in your business wonders why should adding those “small” features take so much time? Why is software delivery like pulling teeth? Why are younger companies who hardly know the industry or have the experience grow faster? Do you sense your development team’s productivity and morale is at an all-time low? If this all sounds a bit familiar, chances are, your software product or offering has accrued something called technical debt.
Friction in software development
What is technical debt? You can think of technical debt as an analogy with friction in mechanical devices; The more friction a device experiences due to bad design, wear and tear, lack of lubrication, the harder it is to move the device, and the more energy you have to apply to get the original effect. In 1992 Ward Cunningham introduced it to communicate the delicate balance between speed of software delivery and rework in pursuit of delivering functioning quality software. What typically happens is foundations are laid, corners are cut for any number of reasons that seem defensible at the time; But in the fullness of time, the relentless accretion of code over months, years, and even decades quickly turns every successful project into a legacy one. Below are some of the ways technical debt manifests.
- Fragile code – Changes to one feature will break other features of your system
- Decreasing rate of developer productivity – Velocity seems unattainable
- System and application degradation of quality– Prone to more defects, or crashes
Causes of technical debt
Getting to the root cause of technical debt can be daunting and it usually is a combination of reasons that would have caused it. To a certain, some causes may affect the software to a larger degree than others. It is almost a perplexing art to find which affects the system more. Causes can be categorized into two.
- Unintentional Debt: Symptoms emerge much later in the software development lifecycle, so the causes are hard to track down. Teams do not know when or how the debt began and, worse, they don’t know how to get rid of it.
- Intentional Debt: At some point, teams decide to introduce technical debt to achieve some objective. This intentional debt can be short term when developers intend to rectify the technical debt within the next few releases. It could be long term when the business doesn’t budget and allow for it.
Below is a diagram that shows where the cause for the most common technical debt may occur.
Can we get rid of technical debt?
Does this mean that we can write code or build software without technical debt? The short answer is No, all systems have technical debt. An important step toward getting ahead of technical debt is to understand the realities and complexities of software development that cause the debt. Managing technical debt is not a one-time activity; It is an ongoing, integral part of the software development lifecycle. In some fashion business leaders who lead technology businesses or teams have to budget and recognize technical debt as something that affects business than just as a problem with diva developers/engineers who just want more time and resources. Following this blog, our next article will talk about some of the ways you can begin identifying and start addressing technical debt within your systems. We are also offering one free technical debt identification half a day workshop every month. This would be exclusive to your business, your codebase (including a technology and code audit).
Click on the button below to submit your entry to the workshop.
