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
Is your organization currently experiencing technical debt?*
The vast majority (93%) of respondents are currently experiencing technical debt, and 7% have experienced it in the past.
*Respondents who had never experienced technical debt or were unsure were eliminated from the survey.
Which types of technical debt has your team experienced?
The most common types of technical debt were architecture (67%), infrastructure (58%) and code (53%). The least common were people (20%), requirement (16%) and service (15%).
Design 36%, Process 28%, Tests and test automation 21%, Bugs 20%, People 20%, Requirement 16%, Service 15%, Not sure 1%, None of these 0%, Other 0%
n = 300
Please join or sign in to view more content.
By joining the Peer Community, you'll get:
- Peer Discussions and Polls
- One-Minute Insights
- Connect with like-minded individuals
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.
What is your opinion on technical debt?
n = 300
Very positive 0%
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.
What are the most common causes of technical debt?
n = 300
Changing goals during development to better align with the business 25%, Delays due to unforeseen challenges or obstacles during development 20%, Other* 2%, Not sure <1%
*Other included prioritizing “new” over modernizing/maintaining existing functionality, lack of investment, legacy systems, obsolete frameworks, and prioritizing bug fixes over coding new features.
60% of respondents manage their technical debt by documenting it during development, while 10% said they’re not currently managing their technical debt.
Which approach(es) are you using to manage technical debt?
Other* 2%, Not sure 0%
n = 300
*Other included continual service improvement evaluation, documenting legacy issues and a plan for remediation, risk analysis tied to the debt, understanding what we have and could have, and assigning specific percentage of effort to decrease debt each sprint.
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.
What challenges have you experienced with technical debt in your organization?
Poor quality code 25%, Customer churn 13%, Lost sales 5%, Other* <1%, None of these 0%
*Other included slowdown in new solutions development and deployment.
n = 300
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.
What benefits of technical debt have you seen in your organization?
Smaller engineering teams 19%, Scalability 18%, None of these 10%, Other* 1%
*Other included meeting short-term requests, option to replace and go to market, and greater awareness of the debt.
n = 300
[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.
Respondent Breakdown
