On technical debt (now with chickens!)

Technical debt, meant as the damage created to a codebase by hastily implementing a feature (and wrecking the codebase’s design in the process), seems to be a foreign concept to some managers/customers. Maybe they know and they just don’t want to listen, I’m not sure. Anyway, I thought of a little story that I might use the next time I’ll have to explain the pricing of some new feature:

A farmer has three chickens. Each chicken makes one egg per day.
The farmer is in business with a local grocer. The grocer buys two eggs per day from the farmer, so he can sell them at his shop.
All is fine with the world until the grocer shows up at the farmer’s place:

Grocer: Hey there. I'd like to have some chicken meat today.
Farmer: Meat? That wasn't in the agreement.
Grocer: I know. But I really need meat. It's for a Business-to-Stomach Enterprise Poultry-as-a-Service Platform I'm planning.
Farmer: What?
Grocer: Important stuff. Can you give me some?
Farmer: Well, that's not so easy - I'd have to hatch eggs and wait for the chicks to grow... I think it'll take a month or so.
Grocer: A month? That's way too much... I was thinking more on the likes of right now.
Farmer: Nature has its times, you'll have to wait a little bit.
Grocer: Hm, why don't you just kill one of the chickens? That way, I'll have my meat and you can still produce two eggs per day. You don't need more, right?
Farmer: Well, I don't think it's a good idea. That would put me in a tight spot in the case something happens to one of the other chickens.
Grocer: Come on, nothing's going to happen... and I really, really need that meat! Can you do that?
Farmer: Okay, I guess I can...

And so, the farmer picks his cleaver up and sends one of the birds to the Creator. The grocer gets his meat and returns to his shop.
One week later, the grocer pays the farmer another visit:

Grocer: Hey there!
Farmer: Hey, what's up?
Grocer: Listen - the meat was great. Actually, it was so great and it sold so well that now we absolutely need at least another chicken. By tomorrow.
Farmer: That's not gonna happen. If I give you another chicken then I'll not be able to deliver the two daily eggs that were in the pacts.
Grocer: Oh please come on! Customers want meat, and I've already promised it for tomorrow...
Farmer: No, I can't do that. I'll not be able to honor the contract if I do, do you understand? Eggs will not be guaranteed if I do that.
Grocer: But I really, really, really need the meat! By tomorrow! Otherwise customers will get mad, the earth will shatter and the world as we know it will end! Give me one of the chickens, now!
Farmer: Well, if you want it that bad, take it! Again, eggs are not guaranteed from now on, understood?
Grocer: Yea sure, got it. But you're a smart guy, I guess you'll figure out how to make it work anyway. Bye!

And the grocer leaves for his shop again.
The day after:

Grocer: Hello. What's wrong with the eggs?
Farmer: What do you mean?
Grocer: The eggs. Actually, the egg. There's just one. What happened?
Farmer: What happened? I had three chickens. You took two. Now there's just one. One chicken, one egg. I though I was being clear about that.
Grocer: But that wasn't in the pacts! The contract states it right here - you owe me two eggs per day! Now what will I say to my customers?
Farmer: Well, I was very clear about it. Nothing I can do about that.
Grocer: Okay, okay, sheesh, forget it. Talking about something else... it would be nice to have some meat. Can I have some?

So, don’t be a farmer – refuse to irreparably damage your codebase for the needs of now and, if you’re forced to do so, don’t take responsibility for the wreckage – and don’t be a grocer – don’t ask for the impossible and assume the responsibility for your decisions.

P.S.: no chickens were harmed during the writing of this blog post.



  1. This should be required reading for all non-programmer members of the IT industry.

  2. Sebastian Gozin · February 27, 2012

    I feel like there is a farmer missing in this story. The one that tells the grocer that the farmer he has a pact with is some new age farmer who preaches a lot about the wonders of nature but without any real world experience.

    So really he’s an amateur and the grocer would do better and form a pact with him instead.

    • Thomas · February 28, 2012

      Also the grocer’s nephew, who has once fried an egg and thus could easily guarantee the required supply of eggs with only half a chicken.

      • Clint · February 28, 2012

        You win the intranet my friend!

  3. Jason Smith · February 27, 2012


    • Roger · February 29, 2012

      No, that’d be a goose. An entirely different spec.

  4. Tal Rotbart · February 28, 2012

    I find that to better communicate the outcome of technical debt to the business, measure it as “Cost of Change” rather than tech debt.

    Make sure the business can visually see that the Cost of Change carries an interest – as we know that tech debt grows as more code is written on top of it.

    A good way of visualizing it is by having a Cost of Change graph right next to the Ramp-up graph on your wall- and make sure it consistently accrues interest.

    • Sebastian Gozin · February 28, 2012

      If you figure out a way to practically build such a graph let me know.

      Mainly, where do you get the data to support that graph? It’s not like the incoming bugs, static analysis results and the like can be convincingly with a decision made yesterday, last week or a month ago.

      And honestly, why should we have to? When the heating in my home is broken I call the landlord and I wait for it to get fixed the next summer.
      What’s that? You don’t like spending winter without heating? Well har har mate.

      If I can’t do a thing about that then what is going on with people giving a damn I try to prevent them losing money on crappy code?

      • Tal Rotbart · February 28, 2012

        Tech Debt cards should carry an estimate when put on the wall.

        The aggregate estimate for Cost of Change should grow each iteration with an interest rate — I’d say approximately 5% every iteration but this is project specific. It would be more for legacy code bases and less for code bases with meaningful and high test coverage.

        So the total of “Cost of Change” for an iteration should be = (previous cost of change x 1.05) + (estimate on added tech debt cards).

        Graph this on the wall and you will see the business starting to understand and be concerned about the cost of change.

    • Martin · February 28, 2012

      … I thought the basis behind XP (at least, and maybe most of Agile) was that the cost of change was constant and low … ?

      • andreadallera · February 28, 2012

        The cost of change is low assumed that you can follow best practices like unit testing and pair programming and such.

        Agile without customer committment is just an empty shell. You can’t just say “agile!” and make all problems go away like magic. If you want that low cost of change, you have to be ready to invest. If you’re not, you slay chickens (and then blame the “executioner”?)

        • Martin · February 28, 2012

          What I’m questioning is the idea of putting a ‘Cost of Change’-chart up on the board. It seems to discourage the customer to ask for changes. That doesn’t seem to be “including the customer” in the project. IOW. it isn’t a very agile project, no matter the number of unit-tests and pair programming sessions.

          Another thing is equating ‘Cost of Change’ with ‘Tech Debt’. I think we might be headed down the wrong lane here.

          • Tal Rotbart · February 29, 2012

            Mounting tech debt represents the biggest risk to low cost of change in an agile project.

            Rising tech debt means rising cost of change — representing that cost to the business is meant to encourage them to see the business benefits and cost effectiveness of dealing with tech debt early.

            It includes the customer _more_ in the project, not less– as it translates a ‘techie’ concept into something they can grok and make informed decisions about.

  5. aaaa · February 28, 2012

    I miss the part where farmer get sued/fired for heaving bad attitude.

  6. Henry Miller · February 28, 2012

    Intentional technical debt is not nearly the problem as the unintentional part. It is easy to explain the risks, and the costs are easy to estimate. If it is worth fixing (some is not!), it is easy to do.

    The hard debt is the unintentional debt. That is where I’ve grown up enough to regret what seemed like a good decision to my younger self. Often new techniques are developed, and prove themselves: now -in hindsight – you realize that your program would be much easier to work with. While your competition with newer codes bases is rushing more and more features out the door you can’t keep up. Paying off this debt is the only chance you have to keep up, but if you pay it off you will go out off business when customers leave for more features….

    • mangocats · February 29, 2012

      “While your competition with newer codes bases is rushing more and more features out the door you can’t keep up.”

      What I have experienced far more often is being part of a small innovative firm, jumping out 2-3 years in front of the (larger, richer) competition, raising arms in victory, tripling “our” sales and business, often at the expense of the competition – but, in the end, they still have 98% of their revenue stream intact. 5 years later, a team of 30 at the larger company has steamrolled past us with a broad, obvious feature set that we have no hope of keeping up with. Sales dwindle, move on to next bold innovative project,,,

  7. Sampath Prahalad · February 28, 2012

    Excellent one. A Must read for all Business owner / Product Owners and for the implementation teams.

  8. Andy · February 28, 2012

    What’s this? So now we are using a parable to explain a metaphor… to explain the evolution of codebases ?

    Next it’ll be a simile to explain the parable to explain the metaphor…

    Then it’ll be a fable to explain the simile to explain the parable to explain the metaphor…


    • andreadallera · February 28, 2012

      I put a metaphor into your metaphor so now you can read a metaphor while you read your metaphor?

  9. Jan · February 28, 2012

    You’re painting the picture of the Grocer as being the bad guy and the Farmer as the victim. However, isn’t the Grocer the one giving the Farmer the opportunity to grow and expand a business/service?

    At Farmer school did the Farmer learn about raising living organisms for food or raw materials (def. http://en.wikipedia.org/wiki/Farmer)?
    His business seems to be dependent on three hens, no plan for growth. Did he think he would only ever need to produce 2 eggs a day.
    Hens have a finite lifetime (10 years?), surely you’d want to ensure you could fulfil this contract on an ongoing basis and perhaps offer eggs to other Grocers.
    (If he only has hens, the Farmer should probably invest in a cockerel too, else the business has no chance of growing…)

    Fair enough, the Farmer cannot second guess what the Grocer wants next, but by investing in his own hen house he is capable producing more eggs, and thus more meat and is capable of responding more quickly to the ever changing demands of the Grocer.
    If the Farmer cannot respond to the changing demands of the Grocer, then I wouldn’t blame the Grocer if he sourced his eggs and meat from another Farmer in a different county.

    • Nick · February 28, 2012

      That’s all very well, but if his customer base is one grocer who buys two eggs, then he has to have capital set aside for extra feed for extra chickens until he grows his customer base to include other clients, be they for meat or for eggs.

      Or he could grow his business the way too many companies seem to, by taking advance orders on the promise of meat and eggs to come before the new chickens even exist, using the advance money to pay for the feed, and hoping to hell the fox doesn’t get in the henhouse and raid the deliverables in the mean time.

      • Jan · February 28, 2012

        If the Farmer is not making an operating profit, then he won’t stay in business for long. Profit buys feed.

        If I were the Grocer I would find additional Farmers and not keep all my eggs in one basket.

        • mangocats · February 29, 2012

          This Grocer doesn’t seem interested in the expense or hassle of managing multiple farmers.

  10. Kurt Stephens · February 28, 2012

    I’ve worked with more than a few tech managers that will dismiss a known mess or poor design as “technical debit”, but I’ve *never* seen the originating manager actively plan to “pay it off”; like taking out a loan without any intention to ever pay it off — “we’ll get around to it later”.

    Tech debit is hard to quantify but it’s compounding interest rate is always increased by desire for change. Lean startups and agileists could weave technical debit management into business plans; I’ve never seen it in practice.

    At some point the debit goes into default — new features are impossible under its weight and a full rewrite from scratch is attempted at great risk and cost. In many cases, businesses have no clue what debit they are under — it’s been hidden from them by project managers.

  11. William Saunders (@Montagist) · February 28, 2012

    It’s a solid attempt at explaining Technical Debt through a metaphor, but I think the reality of technical debt is a little more nuanced in that it’s not just the havoc wreaked on a codebase through hasty implementation, but something that can arise through doing any work on code whatsoever. Like a really complicated game of Snake, every programmatic choice increases technical debt by lowering the number of options you have to go down other paths. Of course you -can- always go backwards, it’s just a question of how much you’ll have to rip out, tidy up, and reimplement to get there.

    • mangocats · February 29, 2012

      Some of this is addressed by adequate design work… with actual specifications, you can write and execute tests, so you at least know what you are messing up with your changes.

  12. Chris · February 29, 2012

    In my case, it’s one hand saying, “hurry up and buy 10 more chickens that require the premium chicken feed and may or may not produce the same amount and quality of eggs”, and the other hand saying, “you cannot buy more chickens or more farm hands, but you need to produce more eggs and they need to be rainbow colored.”

  13. Ben Hardy (@benhardy) · March 1, 2012

    Brilliant. Thank you.

  14. arrasz · March 1, 2012

    Just awesome! Will use this little story the next time too 🙂

    Thanks a lot for sharing!

  15. Tommy King · March 1, 2012

    Nice article, great analogies. Even a complete idiot can grasp the concept (assuming they’re not a farmer).

  16. Pingback: Real SMB IT: On ‘Technical Debt’ | Strategic Technology
  17. Asit · March 6, 2012

    Amazing article. Thanks for sharing!

  18. Pingback: 用鸡讲解技术债务的形成过程 - 博客 - 伯乐在线
  19. Pingback: 用鸡讲解技术债务的形成过程 - 读书 - 什么是 - 代码 - 如何 - 客户 - 技术 - 技术债务 - 理解 - 码农 - 经理 - DigDeeply's Blog | 个人博客 | 技术博客
  20. Pingback: 用鸡讲解技术债务的形成过程 | This Is NetSurf Blog
  21. Pingback: Weekend Link Round Up | Only in Seattle
  22. Pingback: 技术债务(母鸡的遭遇) | 全信息-互联网深度阅读体验
  23. Pingback: 技术债务(母鸡的遭遇) | 极地 EA163
  24. Pingback: 三两带走 - 龙安的博客
  25. Pingback: 技术债务 | xuweiqiang的纯技术blog
  26. markdrago · April 24, 2012

    I recently wrote up a post about tech debt that takes a different approach: http://markdrago.com/blog/2012/04/23/a-pragmatic-exploration-of-tech-debt/

  27. Java Tutorial · October 8, 2012

    Technical dept and architectural debt are two terms designers and architect use for there own benefit.

  28. Brad · June 28, 2013

    Reply from a manager about the story:
    “I have an answer.

    The farmer did not plan well. What did he do with the extra egg a day from the third chicken before he agreed to kill it? He could and should have hatched those into chickens! Think how many chickens he could have had if he did that. It’s all about planning for the rainy day, in this case planning for the killing day)”

    Suggested modification:
    • The only food the farmer has is the extra egg
    • All the money is going to the mortgage

  29. Pingback: 用鸡讲解技术债务的形成过程 | 华基

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s