We recently interviewed David Wood on our podcast Getting Apps Done, and during the conversation David reframed “technical debt” as “technical credit”.

Technical Debt is the concept that bad code decisions “build up” over time and eventually have to be paid off by being fixed. This usually takes the form of a “refactoring” project that has to happen as a prerequiste for some other feature that the boss wants.

Technical credit contrasts technical debt by treating code quality as “credit” towards new features. You make it better so you can afford the time and effort to add new capabilities to your product.

How about an example: Imagine a product with lots of legacy code, overly complex, poorly documented, and needing a refactor; a rough draft of code that was never cleaned up. To add “shiny new feature” into that framework of code will require five weeks! And each additional feature is the same, another five weeks! However, if you spend the first five weeks refactoring, cleaning up the existing code and adding more flexibility, then additional features will only cost one week!

As a developer, we really care about how code looks. A lot of what makes it fun to program, is finding simpler and more elegant solutions to problems. We view all those things that we knew about but didn’t fix as “debt”, something we didn’t build “correctly”. But to a stakeholder, the person who is requesting the new features, none of that is important. What they’re interested in is solving a different set of problems using the result of the problems that were solved by the developers.

A stakeholder can view the refactoring, the cleanup, as ‘work’ that gains them credit to add new features. Much like how you go work, sacrificing freedom so that you can afford more interesting things in life, the stakeholder puts their money and resources into doing that work so they can pay to solve more interesting (to them) problems. They’ve earned “credit” towards purchasing those new features, new solutions to problems, which might not even be known yet!

In the podcast, David talked about how this message is easier to communicate to stakeholders. They can even see it in action over time. “We did this reworking so we could add this feature.” “We simplified this concept, so that these concepts could be built on top of it.” They can see the story of the why we did something, even though they might now how to do it themselves, which makes for much easier conversations.

There was a lot of other good conversation in the podcast, and I’ll link it here when it’s published!

Stay tuned!

-Kel

If you have any questions or notice anything incorrect or missing, please post an issue or contact me.