Technical Debt: Is It Necessary for On-Time Deployment?
Technical debt can slow progress, but it’s often an unavoidable part of software development. Read on to learn how engineering leaders think about technical debt.
One minute insights:
- Most engineering leaders are currently experiencing technical debt
- Architecture, infrastructure and code debt are the most common forms
- The majority of respondents view technical debt negatively
- Prioritizing one feature over another can lead to technical debt, and many engineering leaders manage it through documentation
- Technical debt can increase refactoring costs, but it can also result in faster software deployment
Most engineering leaders are currently experiencing technical debt and architecture debt is the most common form
I believe all teams experience technical debt to some degree. It seems almost unavoidable! The ability to address this challenge before it becomes a hindrance to progress is not only achievable but necessary for business continuity.
Speed and delivery of software should never be the only priority. Stability and reliability are much more important and reduce future costs of development.
Most respondents view technical debt negatively
More than half (55%) of respondents consider technical debt to be negative. 38% have a neutral opinion of it, while only 8% see it positively.
There is no scenario where technical [debt] will be zero. There would always be business exigencies where prioritisation of time vis-a-vis quality would happen.
Too much technical debt can reduce [the] team’s agility. It will lead to poor quality code and require extensive testing. Eventually, it would impact overall productivity.
Prioritizing one feature over another can lead to technical debt, and many engineering leaders manage it through documentation
More than half (55%) of respondents said prioritizing some features over others is a common cause of technical debt, while 50% said prioritizing on-time deployment over perfect code often leads to it.
60% of respondents manage their technical debt by documenting it during development, while 10% said they’re not currently managing their technical debt.
We try to do 20% sprint time dedicated to technical debt. It is still a struggle to prioritize that over enhancement and features but at least it is not totally neglected.
Technical debt should be treated like any other development task. It should go into the overall plan and be addressed at the right time.
Technical debt can lead to increased refactoring costs, but it can also result in faster software deployment
59% of tech leaders experienced increased costs related to refactoring. Other common technical debt challenges were customer complaints (51%) and unaddressed bugs (47%). Lost sales ranked low, with only 5% of respondents attributing these to technical debt.
Half (50%) of respondents said the top benefit of technical debt is faster software deployment. Achievable deadlines (46%) and reduced development costs (44%) were also commonly cited.
[Technical] debt is always a balancing act. It is impossible to move forward without it, but it can end up holding you back if you ignore it completely.
If technical debt is not repaid, it can accumulate ‘interest,’ making it harder to implement changes.
Want more insights like this from leaders like yourself?
Click here to explore the revamped, retooled and reimagined Gartner Peer Community. You'll get access to synthesized insights and engaging discussions from a community of your peers.