As developers, we all know how damaging technical debt can be: it decreases velocity, reliability, and daily joy. We know that true agile working requires constant refactoring to bring technical debt down. And yet, in the constant drive to develop new features and (if we’re lucky) fix old bugs, our lords and masters urge us ever onwards, faster and faster, feature after feature, until the codebase collapses into a sticky mess.
Technical debt is not merely a matter of programmer-aesthetics, it genuinely goes the heart of what quality development is all about. But non-technical managers don’t get that. To them, code is just code: if it works: it works, and if it doesn’t: there are plenty of hackers looking for work who are more competent than you.
In order to align our bosses’ needs with ours, we need to be able to express what technical debt is in language which is familiar to them. That is the language of finance. In this talk, we will explore how to quantify the cash value of code, how to measure technical debt, and how to find the actual interest rate the business is paying for it. This is how you can beat the bean-counters at their own game, and put the joy back into your code.