Tech Debt Developer Survey Results 2020 - Impact on Retention

Last month, I wrote a blog post called Technical Debt is Soul-crushing. In it, I discussed the effects of tech debt on software developers and how it makes them unhappy. I wrote it because, being in management for several years now, I have seen how people discuss tech debt as a product or engineering problem. They completely overlook or ignore its impact on people.

For software developers, it is very frustrating to work on a codebase that has a high amount of tech debt. They feel unproductive and handicapped. This creates an atmosphere where people start thinking about leaving and they do soon as they find a better option.

Because the blog post was getting good amount of traffic (10k views in a week), I decided to add a survey. The survey is closed and the results are in.

68% of Developers Said They Work on Products with High or Very High Amounts of Tech Debt

No large software is tech debt free. At least, I haven’t come across one in my life. Some have more, others have less.

Not a single person said that their product contains ‘No tech debt’.

---

50% of Developers Are Likely or ‘Very Likely’ to Leave Their Jobs Because of Tech Debt

27% percent indicated that they think about it, but aren’t sure.

---

Question: Is Your Management Aware of Tech Debt and Are They Taking Action to Pay It Off?

I asked this question to see if there’s a correlation between developer dissatisfaction and management or leadership being aware of the problem and taking action to pay it off. Here are the results.

---

Question: How Long Have You Been Working on the Product with Tech Debt?

Here are the results.

---

Survey Methodology

117 software developers from all over the world took the survey. The majority were from the USA, followed by Canada, Australia, Germany, India, Russia , UK and other European countries.

The survey ran in February 2020.

91 software developers took the web survey. 26 respondents were from my personal contacts. Senior or Lead software developers mainly from the USA and Canada who use Java. I limited my contacts as not to introduce sample selection bias.

---

Before I continue further and look at some comments from the survey, if you enjoyed this post, please share it on Twitter, Facebook and other sites. It helps me grow. The links to share are at the bottom.

Types of Tech Debt

I asked survey participants to identify the type of tech debt present in their project. Here are some of their responses.

• Poor code, outdated libraries, lack of documentation
• Outdated libraries, a mix of design patterns, poorly designed code, obviously-slower-than-it-should-be performance
• bloated monolith - lack of processes, no time allocated for reducing tech debt - lack of documentation, onboarding is not trivial - low amounts of automated testing - compiler warnings mostly ignored - static analysis tools not included in the dev process. running such tools on the codebase produce non-trivial warnings (that are not related to readability)
• Poor code, bad design choices, lack of unit tests, no documentation, haphazard architecture
• Outdated
• no design no docs no tests no separation to concerns no competence
• legacy code base
• Poor design choices as the product evolved, mostly from a technical perspective dealing with the divide/chasm between frontend & backend, where and how is the data being transmitted.
• poor coding practices, outdated libraries (largely from silly backwards compatibility requirements)
• Monolithic processes, lack of documentation, inconsistencies across similar parts of the product, lack of shared code leading to mass code duplication
• tech debt helps me keep my job
• Poor code & design choices, outdated libraries, barely maintained logging & monitoring solutions, lack of documentation, terrible deployment strategy, lack of tests (especially integration tests)
• Large monolith, lack of continuous delivery, vague processes and no central authority for organizing deployments of the monolith, consistent failure to investment in hiring enough people to support the work
• Design docs written without background research, some design decisions made without a design doc
• Zero tests, no documentation, massive code duplication, hardcoded IDs in code as hacks
• Inconsistent use of designs/patterns across code base. Lacking alignment to broader architectural goals.
• monolith, not implemented design principles (especially SRP and OCP from SOLID), outdated libraries, lack of process, lack of documentation
• Bloated monolith, cowboy programming methods, hard-coded stuff everywhere, outdated programming languages and frameworks, lack of process
• outdate languages and frameworks, monolithic structure, coupling between components that should not be connected
• Building an in-house UI framework built on another external framework that’s not supported anymore.
• bloated monolith, poor code or design choices, outdated libraries - terraform, lack of processes or documentation, Left over AWS infrastructure for services not used.
• in-house frameworks flaky tests and code (sic!) unstable test hardware (the setup is done poorly), often redesigning code that wasn’t even updated to the previous design
• Bloated monolith, poor code and design choices, far too much “duct tape” accumulated over decades.
• lack of documentation, lots of invalid inconsistent data in the database, lots of code which is (presumably) not used anymore with no easy way to be sure.
• Framework built 10 years ago in house
• Poor abstractions. Architecture requiring substantial boilerplate.
• Complicated event & callback system, varying programming styles, lack or processes.
• lack of processes or documentation, poor SE practices, no code review

---

Other Comments from the Survey

I asked readers to leave comments on the survey. Here are some of their comments.

• Management actively acknowledges it and we even prioritize among technical debt, but the technical debt items never make it into work streams because it’s never seen as important enough.
• I actually left because of their inabiiity to make a choice
• Senior developers are the problem. They added tech debt because it is their job security
• it’s hard to tackle the tech debt when most of the engineers are not very good. they simply don’t know how to write better code, and don’t always see the virtue in better designs when they’re presented. they also don’t know their tools very well (git rebasing and automated refactoring are foreign to them).
• One of the curious things I’ve noticed is that our company is struggling financially, which means addressing tech debt is de-prioritized over new features that might bring in more revenue. However, I think a lot of our issues are related to our tech debt (such as systems being degraded over the weekend without us noticing due to poor monitoring). For whatever reason, new features keeps winning over fixing the issues that cost us users.
• Old services and endpoints are shut down when no longer needed; logging integration APIs record actual production usage.
• Automated tools help find dead code and refactor, but doesn’t write documentation
• I consider tech debt a challenge - I have not been in the project since the beginning, but I do believe we can solve (maybe without going too much in the direction of your other article “overhours”)
• Upper management is very aware of the crippling technical debt load our primary product contains, as it leads directly to numerous bugs – typically found by customers – that are very difficult to track down and fix. However, the immediate dev management doesn’t see that there’s a problem, so nothing is being done to rectify the issue.
• Product features take priority and management is clueless how to fix it

Here are some comments I liked from other sites.

The system I’m working on is indeed soul-crushingly burdened. Everyone knows this: there’s a survey every year and “crushing technical debt” is always the top complaint. I mention it to the bosses, and they go “yeah, we know.” I say we never seem to schedule time to fix it, and I’m told “you’re not in the same meetings we are.” Yeah, but I’m the one that would be fixing it, if we were fixing it, eh?

Now I’ve started actually dealing with the management by treating the debt like it’s impactful.

“How long will it take to do X?” “I can’t predict. The thing that should have taken a day last time took three weeks.”

“Why did the system break?” “Shitty architecture from the start mandated making changes that are impossible to test, and our tests are so flakey it’s impossible to tell whether anything’s broken, so we pushed it out to prod and waited to see who complained about which feature.”

Without something like that, management never actually feels the pain, never understands that it’s not just something hard they’re asking for, but an interlocking tangle of shortcuts that make things 100x as hard to accomplish as they should be.

Oh, I understand this so much. . I am A data analyst who does a lot of programming. We automate Excel spreadsheets and databases tools and stuff using VBA and Python and SQL. The guy before me was not a programmer at all as is often the case in people who develop automated Excel spreadsheets with VBA. Every tool that the client has asked me to update is so horrible that I can’t even Trace through the code To figure out where I can insert a feature. It’s like a puzzle that has no logical solution.

Some of the code has variables that are sprinkled all over that have the same name and then he just repurposes them with new names. I swear all over the code There are blocks that look like this:

A=1

B=A

C=B

Instead of using modular functions and subroutines, every single function is repeated over and over with small modifications made. Because of that the code base is probably 30 times longer than it should be.

The worst part is throughout the code there are comments saying this should be fixed or that should be made better, but it was never done.

I like my job for several reasons, but this code I have to work with causes me to think about quitting probably every month or two.