Focus on Maintainability, not "Tech Debt"

This resource first appeared in issue #101 on 19 Nov 2021 and has tags Technical Leadership: Other

Reframing tech debt - Leemay Nassery, Increment
A Rubric for Evaluating Team Members’ Contributions to a Maintainable Code Base - Chelsea Troy

Once a software product is high enough on the technical readiness ladder - once it’s actually being used by communities - technical debt becomes an issue. The problem isn’t awareness - we all know code should be maintainable and well documented, etc. - the issue is the people systems to support individual developers in deciding to put time into activities that support that.

Nassery describes a rebranding that might help a lot in some circumstances research software teams find themselves in - rather than talking about reducing or eliminating tech debt, talking about building tech wealth, and what that new asset allows - faster development, fewer bugs, etc.

This sounds like a goofy rhetorical game, but I think there’s some value in this. Particularly in our line of work, a lot of people you’d be pitching the wealth-building to were involved in the tech debt in the first place either technically or managerially. By not talking about “debt”, which sounds like fixing bad stuff that happened in the past, it makes it easier to support efforts.

If Nassery’s article is more about getting buy in, Troy’s article is more about implementing activities to get it done. The argument is simple and hard to disagree with - if you want the code to be increasingly maintainable and documented, you need to build those code stewardship priorities into the incentive structure. That means reviewing code based on criteria which advance the maintainable code - flexibility, documentation, discoverability and transfer of knowledge and context, but also in evaluating and giving feedback to the developers on those criteria.