Assess Technical Debt With a Developer Survey

Part of my CTO Coaching

Everyone has technical debt.

Why would you need to assess it if everyone has it and you have it too? Don’t you just need to live with it? You need to assess it to get rid of it. Why would you get rid of it? For technical debt the main stakeholder are developers, not someone outside IT. They need to deal with the bad code and bear the pressure. They go down into unpleasant levels of code. You get rid of technical debt so developers can enjoy their craft again. Also development performance of course, for the CEO who is breathing down your neck. To get rid of that technical debt, you first need to understand in how much trouble you are.

There is accidental and strategic technical debt. Strategic technical debt is technical debt you plan for, the one that is part of your strategy. One example would be the technical debt you take on to have an earlier MVP (Minimal viable product). You pay back that technical debt after product market fit (PMF). There is no need to assess that technical debt, because you know what it is.

Then there is accidental technical debt. The one no one planned for. The one that resulted from wrong abstractions, unalignment with business, bad technical choices, or half finished migrations. How much do you have of that?

Something CTOs don’t use as a tool is surveys. Marketing and HR love surveys. They ask employees how they feel. They ask customers what they like. CTOs and engineering leaders often have a vague understanding of the state of things - people, technology and mood. But surprisingly, contrary to others who want to find out about people, CTOs don’t use surveys.

You can find out a lot of things by just asking. You want to know where the tech debt lies? Just ask developers, they struggle every day with it. Send out a questionnaire to developers and ask them about tech debt.

Prepare the survey by creating a list of all packages/modules/microservices for which you want to learn their technical debt level. You need to put them in the survey. This takes some time the first time you do it, but no time in the next survey because you already have the list. This is also an opportunity to properly delegate a task, grow seniors and give ownership.

Questions to developers in the survey should include:

Rate all packages/modules/microservices by low/high technical debt
Rank all packages/modules/microservices by technical debt
How would you rate the quality of our code from 0 to 100?
What should we do about it?
What do we need to do about it?
Do you think we made progress since the last survey?

Either use a paid tool if your company already uses one. Or use Google forms (be aware of GDPR, it also covers employees if you’re in the EU or some of your remote employees are in the EU).