We Don't Have Tech Debt
But that's not surprising, or even that impressive. Our product and dev team are small and young enough that this makes sense. What would be impressive, is if we could it this way.
Types of Debt
We have infrastructure that needs scaling, and features that we want to iterate on, and architecture that will evolve. But nothing we've built costs us undue interest.
Yes, our immature features do fit the wiki definition of tech debt:
"the implied cost of additional work in the future resulting from choosing an expedient solution over a more robust one" - wikipedia
But if we do the book keeping of the expected value of the expedient features over a discounted future, it works out that the expedient, less robust iterations of features are less work overall for the value they provide. They're optimal.
Sub-Optimal Debt
What I really care about here is the suboptimal kind of tech debt. Debt that resulted from bad decisions made with imperfect information, and that is not fixed even when the bookkeeping says it should be.
I'd guess that the likelihood of sub-optimal tech debt is proportional the number of people working on a codebase, with some other compatriots in the numerator like turnover, stack complexity, and codebase size. It's really easy to make poor decisions (and create debt) when decision making is fragmented across a large eng org. It's also really hard to fix those decisions when a) the cost is distributed (no one person/team feels the cost/pain acutely), and b) the decision making is fragmented.
Avoiding it
So the interesting part is mitigating it as your product and team grow. Here are the levers I know of:
- All the usual 'build a good eng org' stuff said best by Fred Brooks
- Write shit down. Document decisions, known limitations, and intentions for the future and their benefits. Also, make it searchable.
- Track toil and its costs
- Do this so well that it becomes easy to know exactly what debt should be paid off, and when. Specifically, the architecture and debt of the codebase has an equally clear and prioritized roadmap as the product does.
More important now than ever
I'll glibly claim that dev time == figuring out what code to write + writing it.
With LLMs, the Writing part will trend towards 0 . And the Figuring Out part we can speed up (for both people and LLMs) with really really high code quality and documentation.
~Lyon