00:00:16.400
Good morning, everybody.
00:00:21.279
I'm here because I want to discuss extending the metaphorical framework we all use to discuss the consequences of technical decision-making. Or perhaps it's an experiment in self-justification.
00:00:30.640
My name is Sebastian, and I have a metric ton of technical debt. I work for StreetEasy, which is a real estate search engine and portal based in New York City. We started almost eight years ago in 2005 when Rails was at version 0.13.1.
00:00:45.760
As of last count, we now have 212 models, 209 controllers, almost 28,000 commits, and 10 developers working on that code. We've gradually grown from three developers eight years ago to about five or four years ago, and now we have 10 developers.
00:01:01.840
As you can imagine, that means we've accumulated a lot of technical debt. So raise your hand if you have technical debt in your projects. Raise your hand if you're ashamed of the technical debt you have in your projects.
00:01:14.880
Now, changing back to the real estate metaphor, raise your hand if you live with your parents. Raise your hand if you rent your apartment or home. Raise your hand if you bought your house. Those of you who bought your house, are you ashamed of the size of your mortgage? That's good.
00:01:57.840
The concept of technical debt was basically a metaphor invented by Ward Cunningham, who also happens to be the inventor of the idea of the wiki. On Sunday night, there was a speaker's event at New Relic, where I got there early and started chatting with some of their developers.
00:02:06.840
They asked me about my talk, and I said it's going to be about technical debt. An older guy chimed in, saying, 'Oh great, I invented the term technical debt.' I mentioned that I saw his name tag, but I wasn't sure. He started discussing a lot of things about the metaphor—where it came from.
00:02:41.200
He precisely remembered how the idea of technical debt started in a discussion about a project for a financial company. He came up with the idea of explaining to them how some of the decisions they made would need to be revisited and fixed later. The term 'debt' was a good way to convey that concept to them. It started as a metaphor to communicate with non-technical people.
00:03:23.360
Later on at the same event, I met David Heinemeier Hansson, and he posed the same question to me. He said it was an extraction; Ward came up with an idea to discuss a problem and then turned that into a metaphor. That's kind of what I intend to do today. I want to stretch that metaphor and see how far I can extend it before it breaks.
00:03:49.320
It's a metaphor that is also useful for discussing with peers about the decisions we're making, and lately it has been used more in that regard. It's basically the idea that I gladly pay you Tuesday for a hamburger today—deferring over time the cost of a decision while getting the benefits today.
00:04:05.760
Looking over the web and reading about documents, the best definition I found is that technical debt is code that a reasonable engineer in the present wishes was different. Someone wants to change it; that's technical debt. It comes down to the idea of whether a tree falling in a forest has someone there to hear it.
00:04:33.040
Technical debt requires an engineer wishing it was different. If no one wishes it was different, then there's no technical debt. If it works, don't fix it—technical debt is that paid with time. You have to go back and work on things you didn't want to pay upfront, but the interest is paid with pain; there's no doubt.
00:05:03.760
If there's no pain, if it doesn't bother anyone, then it's okay—there's no debt. You're not paying. It's like getting a credit card with a zero percent APR; it's a great tool to manage finances as long as it remains zero percent. The moment they ramp up your interest, you should go back and pay it.
00:05:54.080
This leads us to what we call pain-driven development; when something hurts, by all means, go and fix it. But if it doesn't hurt, let it be. If we're going to talk about the different types of technical debt, I like to use this quadrant: the unexpected and the planned, and the tactical and the strategic.
00:06:23.840
When we talk about unexpected debt, it's that debt that suddenly becomes painful because things have changed. Your company pivoted—something you didn’t expect when you made the original decision, and now, you must adapt to the new context.
00:06:56.160
Then, there’s planned technical debt. This is the idea that later is cheaper—we don't have the time right now to do 100 percent test code coverage because we need to ship code. The cost of delaying it is too high compared to the benefits of getting it out the door right now. The idea is that later, our time will be cheaper.
00:07:45.760
Later, we hope we'll have time to fix it. There's also the plan that later is better—not just cheaper but that with deferred decisions, you will have more information to make a better decision. Developers excel at not following this advice; we want to build things perfectly, proud of our work. We want it to look pretty, complete with tests.
00:08:36.960
But the reality is that getting it right isn’t always feasible, and delaying that until later is sometimes the better decision. The essence of the idea is that good enough is better than perfect.
00:09:02.720
The unexpected tactical debt, where things change around you, can have very high costs. If situations shift suddenly, you might find yourself paying exorbitant interest just to cover unexpected costs. In contrast, strategic technical debt is more like a manageable credit card interest.
00:10:07.600
This credit card can cover routine payments, but it should not become a primary tool. Just as you might sign a short-term lease for housing, developers need to ship features to get paid. Features pay salaries, while pretty code does not.
00:11:30.080
When you sign a lease, you're committing to significant recurrent payments, which bear low or no interest. This creates an expectation of continuous payment over time. In contrast, a mortgage—a long-term financial commitment—allows smaller monthly payments for larger properties.
00:12:06.480
The expectation is that those mortgage payments become less impactful on finances as your income rises over time; this is the leverage that debt allows. You're betting on having more resources down the road.
00:14:14.080
So if you were to plan for a project, remember: good enough today often outweighs potential perfection that you might work toward later. In software, you must think strategically about when you can pay to fix the technical debt.
00:15:36.160
Sometimes, if parts of a project become too painful, we refinance it rather than abandon it altogether. Likewise, developers love to consider starting projects from scratch; however, continuing to refine an existing codebase usually yields better results.
00:17:01.760
That means assessing the existing structure: it may be useful to make small improvements rather than entire rewrites. Managing technical debt effectively involves measuring it and understanding how quickly it can be adjusted based on the developer's situation.
00:18:38.960
As developers, we accumulate a fair amount of technical debt—debt that isn’t currently painful to manage. Often, programmers overlook that as they change contexts, they may want to enforce retraining for new hires so they can easily navigate that code.
00:19:55.760
As it is, understanding when to bring in an expert or adjusting your debt may lead to greater wealth creation over time. Managing that debt means recognizing when improvements become necessary rather than simply hunting for a perfect, pristine codebase.
00:21:47.040
So before moving to bankruptcy, take a moment to understand what your project has achieved, critically evaluate its foundation and whether that is the right approach. Thank you, and enjoy the rest of the conference.