C. Keith Ray

C. Keith Ray writes about and develops software in multiple platforms and languages, including iOS® and Macintosh®.
Keith's Résumé (pdf)

Tuesday, November 23, 2010

High technical debt = slum

Sometimes I think the "debt" analogy is too clean. Brian Foote and his coauthor used many analogies in his "Big Ball of Mud" paper, including "Shanty Town", but I think the best analogy for the products I've seen with large amounts of technical debt is "Slum".

Products with large technical debt are money-makers, in spite of their problems (until the problems cost too much).

Slums have slum-lords, who profit from lack of maintenance, who are ignoring the pain of the inhabitants (developers and tester), and who are also ignoring the benefits of a clean environment... (of course, you can only take an analogy so far).

Still, it takes an empowered group of inhabitants to transform a slum into a desirable place to live and work. That requires management support.


  1. I like this analogy. I think it's fair to say that most people think of slumlords as being bad, and wouldn't want to be thought of in that way.

    Then, I went to Wikipedia to see if it could help me back up that statement and found this: "... defenders assert slumlords offer a valuable service for those who care more about price than quality." [http://en.wikipedia.org/wiki/Slumlord]

    That really hits home. I think one of the problems with the software industry is that purchasers may pay more attention to price than quality, if only because it's often difficult for them to evaluate quality before purchasing, so they end up assuming some level of quality that may not be accurate.

    It's interesting to consider. But I agree that software slumlords are bad and the analogy is good.

  2. As much as I like the analogy of "software slums," I don't want to go around calling managers "software slum lords."

    I think some companies and managers get into a high technical debt situation accidentally... much like a situation I experienced when I was still in college.

    My hand-me-down car when I was in college was a Chevy Impala. I rarely took it into a full-service gas station (they used to have those -- see "Back To The Future" for an idealized example) and therefore I rarely had any maintenance work done on that car. One day, half-way home from college with a bag of dirty laundry in the back seat, smoke bellows from under the hood and the car stops working. I'm not a car guy, but I could tell something was wrong.

    That experience taught me that cars needed maintenance. To a non-technical manager, lack of software "maintenance" is just as invisible to them, as the engine under a closed car hood was invisible to me.

    Until the managers are taught the recognize the symptoms of technical debt, they don't see a problem. Programmers also need to learn how to recognize and treat technical debt, and how to talk about it with managers.

  3. I wouldn't be so quick to give managers the easy out. It is a fundamental function of their job to understand the shortcomings of the projects they oversee. Managers should actively seek to identify and reduce technical debt rather than relying on grass roots protests for enlightenment.

  4. It would be injustice to just call the Product Owners and managers as Slum Lords. As most of the times these people do not have a greater length of view towards the Technical debt. Most times the technical debt of the product is miscalculated stuff for e.g. The developer will not be able to give enough visibility to the managers / architects on the design changes / re factoring unless there is a strong review process in place.

    However I agree... You need a group of empowered people to help reduce the Technical debt, before your code asks for Mercy killing.... Refactoring is needed often to reduce your tech debts. My recent post on Code demanding Euthanasia ...http://pm-better-than-sex.blogspot.com/2010/11/is-your-code-demanding-euthanasia.html#disqus_thread

    Sameer Shaikh

  5. Nice analogy.

    You said: Products with large technical debt are money-makers, in spite of their problems (until the problems cost too much).

    In the preface to Implementation Patterns, Kent Beck says: "Actually this book is based on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. However, I still believe that quality of code matters even if it doesn't provide control over the future."

    And in Clean Code, Uncle Bob says the following about Kent's passage: "I disagree! I think that premise is one of the most robust, supported, and overloaded of all the premises in our craft (and I think Kent knows it). We know good code matters because we've had to deal for so long with its lack"

  6. Ugly code that isn't earning money gets thrown away. When the problems in slum-code cost too much, sometimes that results in real-life bankruptcy.

    We, as developers, have to educate ourselves and others about technical debt, so we don't have to live and work in code-slums.

    I think good code matters in the following ways: it is less expensive to make changes (slums make some money, but healthy neighborhoods make even more money), it allows higher morale among testers and programmers, it allows for non-technical managers and developers to treat each other with respect.

  7. Way back, when I was a callow youth, Tom Faulhaber responded to an overly-sophisticated design of mine, saying "there is no Nobel Prize for programming." I've never for gotten that, and much as it gave my ego a swift kick in the butt, I took it to heart. I always ask "How much is enough quality?"

    Your last comments about why good code matters is the real key. But there is no single answer: it's a conversation among secs and stakeholders.