Technical Debt: Do Managers (Unintentionally) Force Bad Code?

I still have estimation on the mind. I saw The Impact of Accidental Complexity on Estimates and I was wondering about the effect of management on bad code. Do managers sometimes force developers to write bad code by allowing technical debt? Jay's third point implicates technical debt as a cause:

Introducing technical debt increases accidental complexity, and as a side-effect invalidates previous estimates and increases the likelihood that future estimates will differ in size drastically.

Accepting technical debt now buys you time now. It does increase time to pay back the debt later. I wonder if we have any idea how much time it takes later. I bet we underestimate how much time it takes to undo the technical debt.

4 Replies to “Technical Debt: Do Managers (Unintentionally) Force Bad Code?”

  1. I like to estimate technical debt as part of design in 3 parts – 1) current savings (how much faster I can get to done) 2) the future payback (how much time will it take to undo this) and 3) the future impact (tax in accidental complexity on any project until I pay it back)

    When my management (or my customer) wants to make this decision, I can show them the impact. It may not be accurate, but it is quite telling. sometimes the impact is very small when the compromise is peripheral to the core of the application, but other times, the savings is nominal and the impact is huge. I have never had a manager or a customer say that a total “do-over” is an acceptable compromise.

    My best example is the cost of a cheap model compromise – current savings was a couple weeks, future payback was essentially a do over of the project (4 months), and future impact is a 30-40% tax on every project. How easy is that decision to make.

  2. Johanna,

    The future cost of deferring technical debt today is not really taken into consideration as much as it should be, in my opinion. Many organizations try to react to immediate needs and short-change the development process. It’s usually a reaction to another business issue, surfacing as something like,” Customer XYZ is important to us, and we need to get this feature in NOW!”

    Unfortunately, the impact of technical debt is definitely one of those things that sneak up on you. And if technical debt is incurred for too long, talk of refactoring gets replaced with, “Let’s start over with a new design.”

  3. Johanna,
    In my experience it’s not always management decisions that cause technical debt. On a recent project we were, of course, anxious for the work to get into the workers hands. We pushed hard for functionality in the early phases. The developers delivered – but hid their technical debt. We MIGHT (hard to know for sure if we wouldn’t have pushed anyway) have been willing to wait for functionality but, because we weren’t given the option, we have to have an entire iteration (two weeks) devoted to mitigating technical debt.

    We (the Ops Managers) met with the Dev management team and let them know we absolutely support taking time to deal with technical debt. We want to be on board when the dev team says – “okay, we can do it this way for now but you’ll pay later….here’s why….”

    Communication always goes both ways. Management can’t manage technical debt unless they know it’s happening.

  4. Having been on both sides of the argument I try and push the technical debt issue whenever I see it rearing its ugly head. You can rank the severity of your bugs all you want while putting your mind at ease that you have triaged everything rationally. But at the end of the day, that low-ranked bug could be a deal breaker for Sales, or it might be the exact functionality a customer purchased your product for and now its not there. Its a gamble any way you look at it.

    The hardest part about technical debt is if it originated from an unknown problem that sprung up mid-cycle. We had to put a hack in to get it working, but we need to step back, learn what the problem is and fix it properly. This is good debt, assuming in your next release you are going to fix the problem and make it better for your customer, if not… well yeah it’s bad debt.

    As a developer I find I push the argument a lot more so at the very least the work gets done and on the roadmap for the next release(s).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.