Circle of death

— September 3, 2009 at 22:15 PDT

debt circle

41 comments — [none]

  1. Daniel Tenner2009-09-03 23:59:54

    You forgot the addition of the magic step after sleep debt, which turns the cycle into:

    ... -> sleep debt -> red bull! -> wings! -> improved cognitive function -> great coding -> technical equity -> confidence -> complacency -> cockiness -> laziness -> poor coding -> technical debt...

  2. Tobias Svensson2009-09-04 00:02:41

    It's funny how many people are actually aware of this, no matter if consciously or subconsciously, and are ignoring it anyways.

  3. Michael Deering2009-09-04 00:30:30

    Hit my feed reader at 1:30am as I'm coding away :-)

  4. sandip2009-09-04 00:34:30

    Try to avoid it anyway.....its true fact !

  5. Carlo Pecchia2009-09-04 00:46:34

    How it's TRUE....

  6. Damien2009-09-04 00:48:49

    So true.

  7. Logan Henriquez2009-09-04 00:50:51

    Any advice on how to break the cycle? Reflecting on my own development experience, I think I need to be better at detecting when I need to stop and take a break, and when I need to motor on. Its not just fatigue - I do great work when fatigued, and also do crap work. Its a complex equation of complexity of the problem domain, fatigue, how long its been since I last worked on this bit of code or problem domain, and just the random fluctuation between "smart days" and "not so smart days". There's also this tension between wanting to have extended focus over time on a complex problem domain so I can get the whole thing into my head, and taking breaks often enough so that I don't make mistakes or lose creativity.

  8. The Dragon2009-09-04 02:03:29

    A heart attack while working late on a project for a fussy client does nicely to break the cycle.

  9. S.A. Braford2009-09-04 02:17:56

    @Daniel Tenner - I've had clients in earnest (to get their project moving faster), show their desire to essentially lock me up in an office for a weekend with just a case of Redbull, svn and TextMate.

    Needless to say, I declined.

  10. iain2009-09-04 02:33:36

    @S.A. Braford: Yeah, I would only do that with coffee, git and vim ;)

  11. Vitrious Coder2009-09-04 03:55:54

    The Vicious Cycle of Coding never stops! Until you stop everything and hit domai or playmate sites, needless to say, having a porn window open freshens up your cognitive, interspatial, visuo-spatial, econo-mechanical, cyclo motor and aquilo pirator skills as my brain has found out.

  12. Ben Griffiths2009-09-04 04:11:06

    Yes, but I wish you wouldn't use the term 'technical debt' so broadly.

    You're really talking about something like 'sub-prime technical debt' - no real assets, and over-leveraged beyond reason.

  13. Al Mendoza2009-09-04 04:51:11

    Yes but integrating all of the porn videos with psiral dynamics makes so much sense. You could probably equate the domains of male and female for about A through E and that should cover at least 30 megabytes per second FIOS.

  14. Kevin Lawver2009-09-04 05:03:25

    Logan, the easiest way to break the cycle is to work on providing accurate estimates for how long it takes to do something, communicating when things go wrong and be "strong" when your estimates are challenged. It took me several years to realize that if I caved and lowered my estimates, I was setting myself up for pain later on. A confident, "I'm not lying. That's how long I think it will take me." usually works.

  15. SD2009-09-04 05:08:12

    ha ha true ..very right..

  16. Schalk2009-09-04 05:11:33

    I am currently rockin this cycle :(

  17. Stephan2009-09-04 05:12:10

    True, and - sadly - also a de-facto industry standard process...

  18. John Davis2009-09-04 06:12:17

    Wow, aint it the truth!


  19. James Adam2009-09-04 06:56:11

    I'm sure plenty of people know and understand this already, but others coming across this may not: there's a difference between 'technical debt' and 'writing poor code'. The latter can certainly be a product of a tired mind, but the former is an active choice.

    Technical debt is a conscious trade of some short-term loss in code quality against some expected short-term benefits. However, it doesn't mean that the software doesn't work properly, or has bugs; it just needs refactoring.

    Accruing technical debt is a perfectly valid strategy when building software, if used appropriately. The real problems come, as with all forms of debt, when it is not paid off promptly.

    So, poor coding does not really result in technical debt - it results in buggy software, and of course, late night debugging.

    Good luck to everyone trying to break that cycle.

  20. Josh Susser2009-09-04 08:15:10

    @James Adam: You're right, but there's good debt and bad debt. As Ben noted above, this is sort of like sub-prime, interest-only payments, excessively-leveraged mortgage debt. Or a high interest rate credit card balance you racked up for a trip to Paris where you blew it all on gourmet food, fine wine and fancy shoes. And the thing about technical debt is that, like financial debt, you have to keep making payments on it until you pay it off. So yes, putting down 20% for a 30-year fixed-rate mortgage to buy a solid home to live in sounds like a good choice, and so are many coding choices that lead to technical debt. But there are also plenty of poor coding choice that programmers make from expedience that they don't realize how much they'll have to pay for later...

  21. iSteve2009-09-04 09:19:15

    I agree technical debt starts as a conscious trade off. Management knowingly creates this debt asking the software engineers to make the trade offs all the time, nodding their heads in agreement that we will go back and refactor (or more likely complete the documentation, add the missing regression tests, and actually do the code reviews as those are the first 3 things to "trade off" when it comes time to "just get it done"). However, management then quickly forgets about the decisions/agreements and 2 months later asks why is the bug count is so high!?

  22. Matthew Weigel2009-09-04 09:52:13

    @Kevin Lawver: that helps you avoid falling in, but not getting back out. Others are talking about the parallels between financial and technical debt; the solution is similar. You have to take some time and make the elimination of technical debt the programming priority for a little while. It's always hard and leads to other delays, but the longer you avoid making progress on eliminating technical debt, the worse you're going to suffer down the road when collection time comes.

  23. why am I in this industry?2009-09-04 10:34:19

    Why am I in an industry where so many value their time so little? How little do we want to make per hour? Why is it that I'm always stuck trying to squeeze out some app that someone else estimated for the client, ignoring my warnings of underestimation?

  24. Scot2009-09-04 16:43:00

    I disagree with the emphasis of blaming the individual here, and not the management decisions that lead to this occuring. In my view the systemic problems are much more insidious. I wrote more about that here -

  25. Jon Davis2009-09-04 18:57:03

    It's not hard to break the cycle, actually it's pretty fun. You tell your boss one day, "I'm gonna go home, it's 5 o'clock. I need an evening." (If he tells you no, these bugs need fixing, please stay late, then start considering finding a new boss.) Then go home, watch some TV, play a game, with yourself or with a friend. Go swimming. At about 8:00 PM, take a sleeptime supplement, such as melatonin or valarian root. Then, at the normal man's bedtime (usually around 9:00-10:00 PM), drink a glass of milk, turn out all the lights, climb into bed, and close your eyes. Don't think about coding.

    In the morning, drink some coffee or other caffinated drink, go to work, and start a normal day.

    And when someone asks, "Why did less get done yesterday than is normal," tell them, "Yesterday was the normal day, so that today can be unusually productive."

    Look it's not hard. Be a human being!

    I still love the picture and it speaks to our weakness more than raw truth.

  26. Josh Susser2009-09-04 19:08:44

    I have to say I've really loved the comments on this post. I'm amazed at how a simple diagram with only 16 words ended up such a rorschach with so many interpretations.

    By the way, I spent the last few days working on upgrading an old Rails app to 2.3 and dealing with technical debt accrued on fixture_scenarios, markaby, and various other old technologies that haven't kept up well. Feels like most of the time was spent making interest-only payments and we still have a lot of principal to pay off.

  27. Dujenwook2009-09-04 20:24:53

    Yeap yeap, had to deal with it myself. I was lucky enough to have an understanding boss that would allow me to catch up from time to time, but I was basically updating an application that ALWAYS needed updating so there was never any "catching up." I found myself in deep technical debt quite a few times. I could tell pretty quickly too, if I had to stop and actually "read" the code, meaning I'd hear myself saying the words out loud in my head, I knew I was tired. When I'm well rested and "on" I don't even feel like I'm really reading code. It's pretty awesome.

    /rant (just woke up) :)

  28. Joe Nuxoll2009-09-04 21:05:08

    So true! Great diagram! (I also like the early comment about Red Bull --> Wings! --> ...)

  29. robb2009-09-05 06:18:57

    LOL this is so true. daniel tenner's comment up above is true, too.

  30. Colin Wetherbee2009-09-05 15:30:03

    The phrase "technical debt" gets thrown around my office fairly frequently, and nobody really seems to have pinned down a definition of it. Your diagram is wonderful and is certainly better than how some people perceive technical debt.

  31. murali2009-09-06 04:49:59

    so true.

  32. Caio Proiete2009-09-06 10:24:03

    That's so true!

  33. Lonny Eachus2009-09-06 22:32:49

    But Colin, as others have pointed out above, what is shown in this diagram is a kind of "artificial" technical debt, not the kind most people speak of. "Regular" technical debt might be something like when you set up a model but you know that you will have to modify it later as specifications get refined. Or -- and even this one is iffy -- when you decide that because of time constraints you will wait until after a release to do a refactor. It's all on a big "to do" list of things that need to be done sooner or later, thus the term "debt".

    But the kind of "debt" shown in this diagram is unplanned, unaccounted for. It consists of things that have to be fixed later because you were coding sloppily today. It is questionable whether this should get lumped into the same category. It would really probably fall into the area of bug chasing.

  34. Craka2009-09-06 22:58:51

    This looks Shopped. I can tell from some of the pixels and from seeing quite a few shops in my time.

  35. Josh Susser2009-09-07 08:31:51

    @Lonny: Bad debt is still debt. Getting up early to catch a plane is probably good sleep debt, but being kept up all night by your neighbor's party is not. One is trading some pain in the present for future benefit, the other is just a pain.

    I was probably a bit sloppy lumping the technical debt that accrues from bad judgment (and other sources of poor coding) in with the kind of debt that is consciously taken on and is a valid and sometimes necessary way to make progress. But you have to pay off both of them eventually, and they both can contribute to problems and bugs. It's more expedient to copy/paste some code than to do a class extraction, and that will let you make progress faster. But eventually that can lead to bugs (e.g. fixing it in one place but not in the other).

  36. Sam2009-09-11 11:33:10

    This is totally true and a major problem in our field...not just with developers. The pattern above leads to stressed out testers and support resources. Support tech is up late assisting justifiably fussy customers, get tired, say something to offend customer, customer calls sales rep, sales rep called VP, VP gets pissed and chews out the manager, manager chews out the support tech.

  37. mayic2009-09-11 18:56:31

    if no ideas came out to manage stress try, Red Heat method

    "how you soviets deal with stress?" "VODKA"


  38. J. B. Rainsberger2009-09-18 23:10:29

    Sigh. Shitty code is not technical debt.

  39. Josh Susser2009-09-19 08:45:35

    JB: Please the the preceding comments. We've been through this already. Not getting enough sleep?

  40. Travis2009-09-25 08:07:16

    I'd say that sounds about right...

    and while shitty code isn't technical debt, it definitely IS a result from a lack of sleep... how many times have we pulled an all-nighter trying to finish something, only to see that it's full of bugs we somehow skimmed right over?

  41. Carolina Quedar2009-11-16 07:36:26

    Is the pattern above really relevant??? I mean, different people deal with stress in different ways and it is important for each person to find something that relieves that tension.

Sorry, comments for this article are closed.