Responsible technical debt: not an oxymoron

Kent Beck’s recent talk at the excellent Startup Lessons Learned conference has created some controversy. As somebody who attended the conference and who has been involved in startups for many years, I agree with some things on each side of the argument, and I want to give my take on how to be responsible with technical debt.

The Agile reaction

In the dark days of waterfall, code bases had only two states: being re-written or slowly getting worse. The project would start out with great hope. People would write something beautiful, launch a 1.0, and then spend their time patching it. Inevitably, and despite initial efforts to resist, the code base would go slowly downhill. Gradually increasing technical debt would lead to technical bankruptcy, forcing a big rewrite. Then the agonizing cycle would start again.

One of the key insights of the Agile movement, one crystallized by Martin Fowler’s book Refactoring, was that decay was not inevitable. We could clean things up incrementally as we went, without needing periodic giant rewrites. Another key insight comes via Kent Beck’s Extreme Programming: if we worked iteratively and refactored all the time, then we could start clean and stay clean, forever, ending the cycle of giant rewrites.

As easy as that sounds, it’s actually very hard; every solid Agile practitioner has spent time developing a nose for technical debt, and a hate of it. So when Kent Beck suggested that startups could responsibly create some technical debt, it caused a lot of strong reactions: to some people it sounded like the pope saying that premarital sex and adultery were occasionally fine.

But startups are about learning

For this to make sense, you have to understand two things:

  1. Startups—even software startups—are businesses, not software development projects.
  2. The point of a startup isn’t to create a software product; it’s to discover a sustainable business model.

In a startup, software development isn’t an art for its own sake; what makes sense from a pure engineering perspective may not make sense more broadly. That’s true for any business really, but it’s especially true for a startup. That’s because the main goal of a startup is to discover a valuable business. Discovery requires experimentation, and the amount you can learn is a function of the cost of your experiments.

So suppose I have a new idea for a game. I believe it will be A) fun and B) a moneymaker. I could take a number of months and design it, develop it, polish it, and publish it. Then the market would tell me whether my beliefs were correct. Or I could make a very crude version with 1 level, have some people play it, and see if the core gameplay is enjoyable. That’s my first experiment to examine hypothesis A, fun. If it works, I could put it up on the web, buy a few ads, and see if the game sounds interesting enough to click through and try it. That would be my first test for hypothesis B, making money with the game.

Now if these tests fail, then my code base may be pretty short lived. They say that hard work pays off eventually, while laziness pays off now. The same is true for good development practices. A lot of Agile practices get you long-term sustainability, but they cost you in the short term. For sufficiently small and short-lived pieces of code, worrying about technical debt does not make business sense. Better to invest in more experiments.

Danger Will Robinson!

At this moment, some of my readers are leaping up to say “But! But! But!” That’s what I wanted to do during Kent’s talk, anyhow. Because when businesspeople hear that they can have something quicker, they will often interrupt to say, “Yes! Do that!” As I explain in “The 3 Kinds of Code“, a lot of business/engineering fights arise because engineers are more aware of the long-term costs of short-term thinking. I have seen good teams, even ones otherwise well-versed in Agile techniques, give in to that business pressure again and again, creating giant messes.

So hacking things together, and the resultant technical debt is extremely dangerous, but sometimes very powerful. What should a responsible team do?

I believe there are good ways to handle this dilemma, and will propose one approach in my next post.

15 Comments

  1. Bob MacNeal:

    I watched a simulcast of the Startup Lessons Learned conference at DevJam in Minneapolis.

    I would have preferred a diet higher in the fiber of what’s known about the Learning phase and Customer Discovery, rather than a slight regurgitation of stale agile principles.

    Nonetheless, I am following the Lean-Startup community with interest.

    I like your important reminder that “The point of a startup isn’t to create a software product; it’s to discover a sustainable business model.”

    I liked Kent Beck’s recognition at the Startup Lessons Learned conference that we need to make engineering trade-offs depending on whether we’re learning or building. This is a key recognition from someone with a well-established engineering bent.

    Cheers.

  2. William Pietri:

    Hi, Bob. Thanks for the kind words.

    The Agile principles might be stale to you, but I think the Agile approach, especially the technical practices focused on sustainability, are not as well understood as they should be. Many of the Lean Startup attendees were businesspeople, who I think still need more education on how to be responsible leaders of businesses with code at their heart.

  3. Markus Silpala:

    William: nice post, as usual. Looking forward to your proposal follow-up. Missed you at #accnc last month.

    Bob: I’m curious. What exactly is stale about agile principles? To me, it seems most firms use the term “agile” plus ~1-3 known agile practices (mostly stand-ups and CI) without actually grokking the principles—nor getting many of the benefits. If they’re stale, it’s because they’ve been left in the package for too long and never used.

    Okay, stretched that metaphor to its limit.

    Disclaimer: I neither attended nor watched a simulcast of the #sllconf. My knowledge is gleaned only from tweets and blogs, mashed up with what I already knew about the lean startup movement.

  4. SKMurphy » Startup Lessons Learned Conference Coverage Roundup:

    [...] William Pietri “Responsible Technical Debt: Not An Oxymoron“ [...]

  5. Ilja Preuß:

    Unfortunately, you don’t say what you think “sufficiently small and short-lived” means. I could possibly agree if it means “a few dozen lines of code, not more than a few days.”

    In my personal experience, I’ve seen a two week “throw away project” being finished in a couple of days, once we started paying attention to code quality after three weeks of trying to control a mess. It then became the seed for a framework that’s still in use and extended.

    As you might imagine, I don’t see any conflict between releasing an early version of a game and maintaining high code quality. I’m assuming that it would be more important to get feedback on whether players would be interested in the games concept after having played a working early version, then to test their tolerance for bugs…

  6. William Pietri:

    Hi, Ilja. thanks for stopping by.

    I certainly agree that some throw-away code will go faster when you make use of some of the quality-oriented practices we Agilists love. If I think of a good name for a variable, I’m not going to call it x just to save 0.05 seconds of typing. If some chunk of code is tricky enough that I’ll go faster writing it with a few tests, I’ll write the tests.

    But for code that may last from a few days to a few weeks, I don’t believe all of our quality-oriented practices are always necessary, or even wise. For example, I’m sure you’d agree we shouldn’t do a major refactoring to properly accommodate a core domain change that we may strip out a week after release. Instead, we can hack something in with a UI-level integration and see whether the new feature is worth the work it will take to do it right.

    I’ll have more to say on this in upcoming posts, so stop back. Or you can subscribe in your favorite feed reader via the upper right corner of this very page.

  7. Ilja Preuß:

    I’m not sure whether I’d agree without seeing a more specific example. In general I’d expect it to be a wise choice to refactor the design closer to the OCP, anyway.

  8. William Pietri:

    Sure. Take Twitter. Not now, but the Twitter of 2+ years ago, before it’s clear that they have much traction. They’ve got a fixed amount of cash in the bank that is getting smaller every week.

    One thing they’ve noticed is that some users have more than one account. (For example, I have a professional one, @williampietri, and a personal one.) The question they’d like to resolve: are enough users excited about multiple handles per account to make it worth a major system change? Or should they stick with what they have? It could be a major feature for top users and businesspeople, or it could be a dud.

    So they do a quick experiment, taking a week to wedge in some multi-handle stuff. It’s pretty hairy hackery, as good chunks of their system assumed 1:1, not 1:N. But they tell their A/B framework to show it to 1% of the users, and they seed it to some of the known multi-login people too as an exclusive alpha test.

    After 2 weeks, it turns out that their users don’t care much. The general population shows little interest. And even current multi-account users who thought they wanted the feature aren’t excited when they see it in practice. So they split the few joined accounts, send out a we’re-sorry email to the handful of users, and rip out the hack. There are a few places where they made the code better along the way; they keep those changes.

    Now there’s no denying that they skipped some refactorings that might make the code better in a design sense. But as I said in the blog entry, this isn’t a software development project; it’s an attempt to discover a sustainable business. So the question isn’t about good design in the abstract, it’s whether spending the capital necessary to improve the design is the very best use of their very limited capital.

    I think what makes people uncomfortable about this is that the answer is a very tactical, “It depends.” Extreme Programming tells us to always turn that quality dial to 11, to always be extremely sustainable. For typical software projects, I think that’s still good advice. But it’s not always correct for startups.

  9. Agile Focus » Blog Archive » The Lean Startup Kanban board:

    [...] Suggested Reading « Responsible technical debt: not an oxymoron [...]

  10. steve:

    I like your twitter example in the comments, helped me understand the concepts

  11. Ilja Preuß:

    So, say you tried that experiment, and now want to get rid of that feature that users don’t care about. How do you do that, without getting rid of the few good refactorings you want to keep?

    I’d postulate that ideally, we just throw away the module with the code for that feature, and the rest of the code stays untouched.

    For that to work, we need to refactor the whole system so that most of it doesn’t need to know a bit about multi-accounts. And those changes should be high-quality. Even when we throw away the feature, we still benefit from those refactorings, because the code improved in terms of SRP, SCP and OCP. We are likely to benefit from those changes in some way for future features, possibly in surprising ways.

    I conclude that the quality of the one experimental module, that we can plug in and out on a whim, then might actually be of secondary concern.

    What do you say?

  12. William Pietri:

    I think that’s true, and that’s an ideal case.

    There are other cases that are trickier, and can’t be usefully analyzed purely in design terms. You have to look at the question in business terms, because in the end the decision to refactor properly or hack egregiously is a cost-benefit question, not a technical one.

    In many projects, we can ignore the business side: revenues and costs are approximately stable, cash reserves are ample, the relationship between features and revenues is unclear, and both features and products are expected to live indefinitely. Given those factors, we can generally get away with only thinking in design terms.

    For startups, though, none of those is true, which means we have to be more careful about when and how we indulge our preference for beautiful code.

  13. SKMurphy » Quotes for Entrepreneurs – April 2010:

    [...] projects—that need to discover a sustainable business model.” William Pietri in “Responsible Technical Debt:  Not an Oxymoron” full quote: Startups are about learning.  For this to make sense, you have to understand [...]

  14. Jason Gorman:

    We’re assuming, of course, that it takes more effort to write better quality code. The available evidence suggests otherwise. I suspect Kent Beck may have been speaking from a rarified perspective, having higher standards than most. His notion of a trade-off may be qualitatively hugely different to what you have in mind. All I can say is that my overriding experience of start-ups is that one day they must become “stay-ups” if they are to survive, and in 99% of cases their code is so horrendously bad that to even suggest they “trade off quality against productivity” is hugely misleading, as they would have all benefitted from a good deal more care and rigour.

  15. William Pietri:

    Hi, Jason. I’m not assuming that; I’m stating it, and would love to see the evidence you have showing otherwise. I agree that better code pays off eventually; I disagree that the payback is instantaneous. If the payback for any sort of quality-oriented practice is anything other than instant, then if some piece of code has a limited lifetime, the utility of that practice is not guaranteed under all circumstances. In startups, a lot of code is very short-lived.

    Have you read the very next article, the one I link in the final sentence? There I explain my way to solve this apparent dilemma.

Clicky Web Analytics