Overcoming the Fundamental Misunderstanding About Technical Debt

Hi, I'm JB Rainsberger. And if you'd like to get in touch with me to ask a question after this talk, then here are some ways that you can find me. Overcoming the fundamental misunderstanding about technical debt. What you probably learned about technical debt before is that there's a bunch of work that we should do now, but we're going to do later. Because we can't do it now, but we hope we'll be able to do it later. I promise we'll do it later. But because we're going to do it later, it's actually going to cost more to do it later than it would cost to do it now. And the longer we wait, the more it's going to cost. And all this can be understood like we're borrowing against our future capacity to deliver features and the longer we wait to do that work, the more the interest is going to accumulate on that debt until we reach the point where the interest is so high that now we're getting into arguments about whether to do now the work that we deferred from earlier or to do new things that you've asked us to do now. And that's why we can't ship your feature right now.

I tried about a decade ago to sound the alarm about the relationship between allowing complication to increase in code and our inability to forecast the cost of future features. I thought I was going to solve the problem forever, but of course I didn't. It turns out that self-righteous arrogance doesn't actually change people's behavior, even if you have a neat gimmick and do a dramatic performance. So I'd like to try to do better this time.

What kind of technical debt is your technical debt? Different people have very different ideas about what technical debt means. The metaphor has really evolved in the way people think about it. There's been a lot of divergence among people. Some people think of it as something as simple as, well, we don't know any better and we're going to learn and it's going to be better later, and that's why the design is not as good now as we hoped it would be.

I'm not here to tell you that the way you think about technical debt is wrong, per se, but you have to admit, the fact that we don't agree on what technical debt means leads to a lot of disagreements about the priorities of managing technical debt and that leads to a bunch of dysfunction. In fact, some of that dysfunction is like the programmers yelling at the managers for not giving them the resources they need to do their job, or the managers yelling at the programmers for not taking the deadlines seriously enough, or even programmers yelling at each other, telling them to stop over-engineering when, in some cases, many I'd say, the people accused of over-engineering are merely trying to take technical debt seriously as a problem.

And I'm not here to tell you that the way you think about technical debt is wrong, per se, but you have to admit, the fact that we don't agree on what technical debt means leads to a lot of disagreements about the priorities of managing technical debt and that leads to a bunch of dysfunction. In fact, some of that dysfunction is like the programmers yelling at the managers for not giving them the resources they need to do their job, or the managers yelling at the programmers for not taking the deadlines seriously enough, or even programmers yelling at each other, telling them to stop over-engineering when, in some cases, many I'd say, the people accused of over-engineering are merely trying to take technical debt seriously as a problem. If we continue like this, I think we're just going to continue entrenching everyone's pet opinion about what the right amount of effort is to put into good design.

You've got people on one side who think that we need to design more carefully, refactor more often, and they point to the mounting interest on the debt to justify their position. Whereas you have a bunch of other people who are asking programmers to design less carefully, to refactor less, to do it in less time, and pointing to vague claims about, you know, other people's debt is bad debt, our debt is good debt, it's fine, just keep going and deliver features. It seems like this technical debt metaphor is almost letting us down, but I don't think it is. I mean, somebody invented this metaphor to solve a real problem. It should help us. Maybe if we go back to what they were thinking, then maybe there's a clue in there somewhere.

So let's go back to Ward Cunningham, who coined the phrase technical debt about 25 years ago, and within less than 10 years, was already seeing people really struggling and suffering trying talking about technical debt in their projects. So he recorded a short video in which he tried to clarify his intentions and his thinking, hoping that it might help. And so, for example, knowing that they were working with technology that they weren't very familiar with, they assumed that they were going to get things wrong. And so, as he put it, it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we'd known what we were doing all along. This is really the power of evolutionary design, the freedom to change the code to match what we understand now and not be prisoners to past decisions because we had to make those decisions when we knew less.

And a lot of people had this idea that we use this debt metaphor as a way to explain to non-programmers why programmers need to take more time to design or to refactor. But that's not what Ward was doing. He was trying to explain to his boss, a software development manager, about why they wanted to take this time to keep the program design aligned with their emerging understanding of the system. And he chose a financial metaphor because they were working on financial software. And he figured that this idea that if we don't keep the design up to date with our emerging understanding that we were going to continually stumble over the gap between what the code said and how we were thinking, that that would continue to slow us down, that that would get worse over time, and that's a bit like needing to repay interest on a loan. And so he could just as easily chose the metaphor from a different domain, but he chose a financial metaphor because they were working in the financial domain.

And at the time, a lot of bloggers, writers, consultants, and I put myself in that group, got confused, and thought about technical debt as an explanation for why we could get away with writing code poorly now with the intention of doing a better job in the future and explaining that as debt. As Ward put it, I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial. So that was Ward's kind of technical debt. A financial metaphor for people working in the financial domain to try to explain this risk management strategy to a software engineering manager, not a non-technical person.

And an indication not of poor technique, but of the ongoing risk of a mismatch between what the programmers understand and what the code says. This is not about trying to explain why we're writing code poorly now with the intention of writing it better later. And so I think that's the fundamental misunderstanding about technical debt. That technical debt is a result of poor or misguided decisions by programmers. Maybe they're under pressure. Maybe they just don't have enough experience. Maybe they just don't care enough. And the cost of those poor choices accumulates over time in compounds like interest on unpaid debt. And therefore, technical debt is either a problem for the programmers to solve, and if they don't solve it, then they're being irresponsible with the project budget or a problem for the business to solve because they need to respect the programmers enough to give them ample resources to execute their master plans.

Well, if this is a misunderstanding about technical debt, then how do we understand it better together? Let's go back to Ward's words, I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial. Now, writing code when your understanding is partial seems odd, but that's what we do all the time. Who here gets to work on projects where you understand the problem perfectly and how to design a solution perfectly before you write any code? We just don't do that.

And it's only gotten more rare over time as we deliver features to the internet every day. The mere fact that we're delivering features incrementally means that we are always accepting the risk of writing code with partial understanding of the problem. Always this problem doesn't go away. And we manage technical debt, obviously, by investing time and effort in realigning the code base with our emerging understanding of the problem. We learn something, we put that learning in the code, we learn something, we put that learning in the code.

Even perfect programmers working in ideal conditions will encounter technical debt merely by trying to deliver features sooner. This isn't a question of people behaving badly or not having enough skill or not having enough time. Even if conditions were perfect, technical debt would still loom large. It's always here. It's not a matter of bad technique, bad skill, bad intentions, not caring. It's not their problem, no matter who they are or is. Technical debt is an ongoing risk that we need to manage together.

And the good news is that managing technical debt doesn't require specialized techniques or specialized tools. It doesn't require vast experience. But all these distorted interpretations of technical debt and what it means to have it and who's responsible for it and how much we need to invest in paying it down, all this leads to the kinds of dysfunctional behavior that makes it hard for us to see what's right in front of our eyes. Now, the good news is you can do it. You can give up these moral judgments about professionalism or caring about the results and recognize technical debt as an ongoing risk that we need to face together. And not to think of technical debt as because it's inevitable, therefore, there's no point doing anything about it, but as something that we need to care about together and be vigilant about together.

That there's no all or nothing when it comes to technical debt, just like there's no all or nothing when it comes to defects. Defects are inevitable because we make mistakes, but that doesn't mean we don't try. And we can adopt the same attitude where technical debt is concerned. In fact, if there's one part of the debt metaphor that we might actually make use of, and that is that getting into debt takes time, it tends to happen gradually in spite of our best efforts. And therefore, while the aphorism goes that if getting into debt takes time, then getting out of debt takes time, we can't expect it to be a problem that they will solve tonight.

Now, that's some good news. Some bad news is that you have to do it. You can't hope your way out of it. You can't wish your way out of it. You can't read your way out of it. The job involves redesigning code continually throughout the lifetime of the project or the product in order to bring it in line with our emerging understanding of the problem and how to solve it. It requires vigilance and determination, and those things are boring. It's very easy to lose interest, to lose motivation and stop. And the only thing, maybe the only thing worse than managing technical debt is not managing It's kind of like being an umpire in baseball. The only time they talk about you is when you're not doing your job. But the good news is there are virtuous cycles here. The more time you spend, the more effort you expend in cultivating the design, the easier it gets.

You improve at it, and it feels easier. The more you change your past choices to align with your current understanding, the less regret you'll have about future choices. Making realigning code a regular part of work reduces resistance to doing it when needed. The key moment is when you read code, feel confused, and have the aha moment. Changing code to reflect your evolving understanding is crucial, no matter the method or technique used. Test-driven development integrates managing technical debt into everyday programming, building beneficial habits over time.

The power of test-driven development lies in instilling habits that treat technical debt seriously. Basic technical principles like immutability and referential transparency aid in managing technical debt. Improving code readability and change confidence reduces resistance to code modifications. Any approach that facilitates putting knowledge back into code is valuable, regardless of the specific method used. Your intent and behavior when reverse engineering lost knowledge are critical in managing technical debt effectively.

Regardless of the approach taken, consistency in addressing technical debt is essential. It's about continuously realigning code with evolving problem-solving insights. The focus should be on behavior in key moments of code review and adjustment. Various strategies, mindsets, or techniques can aid in this process. The key is to actively maintain code quality and alignment with problem understanding over time, ensuring that technical debt is managed proactively.

But I'm Jay Brains, so I have to talk about test-driven development. TDD is helpful as it makes managing technical debt an ordinary part of programming. The refactoring step in TDD conditions us to think about improving code design daily. It builds habits that take technical debt seriously as a continuous risk in feature delivery. Basic technical principles like immutability and referential transparency aid in managing technical debt by enhancing code readability and change confidence.

Reducing resistance to code changes is crucial in addressing technical debt effectively. Consistency in realigning code with problem-solving insights is essential. Various strategies and mindsets can assist in actively maintaining code quality over time. The key lies in managing technical debt proactively by aligning code with evolving understanding.

Accepting the risk of technical debt is inherent in delivering features incrementally. Technical debt, a shared risk, needs to be managed collectively. Disagreements about the right investment in design and refactoring are common. Ignoring technical debt is only safe when the project becomes insignificant, as it can lead to project failure without warning.

It doesn't matter how you do it as long as you do it, which means you can do it in the way that you will actually do as long as you keep doing it. Even when it's boring, even when it seems not to matter, even when nobody is thankful. I know it's not awesome, but the only thing worse than doing it is not doing it.

The cold truths about technical debt are these. The mere fact of trying to deliver features incrementally means accepting the risk of technical debt, no matter how excellent you are at your job, no matter how well things are going, no matter how harmonious the context is. An unconstrained technical debt means that eventually everything grinds to a halt and you'll never see it coming. I mean, you'll know it's coming, but you won't be able to see it coming.

Technical debt is not our problem. It's not their problem. It's a shared risk that we need to manage together. Everyone will disagree about the right amount of investment in design, in refactoring, in paying down technical debt. We'll never... This is not a calculation we can make. We can't put numbers in a spreadsheet and figure it out. This is something that we're always going to be arguing about, forever.

This is something that we're always going to be arguing about, forever. And the only time that we can safely ignore technical debt is when the project actually doesn't matter. I have to admit, I have worked on a few of those. In that context, there are obvious strategies that help. Treating technical debt as an ongoing shared risk to manage by the entire project community and not by thinking of it as a problem that they, whoever they are, need to solve.

We need to reserve some portion of the budget to periodically keep the code aligned with our collective emerging understanding of the system. Repaying technical debt should be treated as an ongoing experiment where we converge towards a balance between producing features now and in the future. The person putting pressure on programmers to refactor less and ship features sooner is not an obstacle but a signal that the project matters. Managing technical debt even more seriously in response to pressure is crucial. Situations require delicate handling and ongoing learning to become a technical leader.

There are complex situations that can't be solved with quick fixes, requiring individual context considerations. Offering generic advice without understanding the specifics can be counterproductive. Managing technical debt is about handling delicate and complex situations sensibly. Becoming a technical leader involves ongoing lifetime learning and navigating conflicts related to technical debt. It's essential to let go of assumptions that lead to conflicts and focus on effective management strategies.

It's a reason to take managing technical debt even more seriously on this project. Go back to Ward's comment that because he knew the risks he was taking on, it was important to manage technical debt effectively. Now, some of you out there, of course, will realize or will tell me that I can't do these things because of that person or that policy. And yeah, I get it. You can fill a bookstore with tricks and strategies for working around these problems. The situations are complex and there's no quick fixes.

It's really risky to offer generic advice and I'm not even going to try. If you want to ask me questions later, we can talk about your context and take all the time we need to talk about it sensibly. But just trying to give you generic advice that might or might not work is actually worse because these are complex situations that you have to handle delicately. This is ongoing lifetime learning. This is what it means to become a technical leader. So is there any optimism here? Well, it depends on what you consider optimistic.

I mean, most people are pretty bad at managing technical debt, so the bar's low. A lot of the conflict related to technical debt just comes from weird assumptions we make that we can decide not to make. We can let that stuff go. You have to take the first step. And managing technical debt is really just doing things that you already know how to do but trying to figure out how to remove the obstacles to actually do them. And you'll never eliminate technical debt, so there's no end to try to reach.

In fact, as long as you keep going, as long as you are trying to reduce technical debt over time, you're doing it right. I find that pretty optimistic. Maybe start here. Read some articles. That doesn't cost anything. Ask me a question. As long as you're willing to wait forever for the answer, that service is free. And if you need help, if you need a better service level agreement, if you need my attention, there's office hours. There's ways you can work with people like me to help you understand how to become the technical leader that your organization needs in order to manage technical debt effectively. Whatever you do, good luck. It's hard out there. Just keep going. Peace.