Click here to monitor SSC

Tony Davis is an Editor with Redgate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the and websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his blog or his author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

Cheating on Technical Debt

Published 23 May 2013 1:30 pm

One bad practice guaranteed to cause dismay amongst your colleagues is passing on technical debt without full disclosure. There could only be two reasons for this. Either the developer or DBA didn’t know the difference between good and bad practices, or concealed the debt. Neither reflects well on their professional competence.

Technical debt, or code debt, is a convenient term to cover all the compromises between the ideal solution and the actual solution, reflecting the reality of the pressures of commercial coding. The one time you’re guaranteed to hear one developer, or DBA, pass judgment on another is when he or she inherits their project, and is surprised by the amount of technical debt left lying around in the form of inelegant architecture, incomplete tests, confusing interface design, no documentation, and so on.

It is often expedient for a Project Manager to ignore the build-up of technical debt, the cut corners, not-quite-finished features and rushed designs that mean progress is satisfyingly rapid in the short term. It’s far less satisfying for the poor person who inherits the code. Nothing sends a colder chill down the spine than the dawning realization that you’ve inherited a system crippled with performance and functional issues that will take months of pain to fix before you can even begin to make progress on any of the planned new features. It’s often hard to justify this ‘debt paying’ time to the project owners and managers. It just looks as if you are making no progress, in marked contrast to your predecessor.

There can be many good reasons for allowing technical debt to build up, at least in the short term. Often, rapid prototyping is essential, there is a temporary shortfall in test resources, or the domain knowledge is incomplete. It may be necessary to hit a specific deadline with a prototype, or proof-of-concept, to explore a possible market opportunity, with planned iterations and refactoring to follow later. However, it is a crime for a developer to build up technical debt without making this clear to the project participants. He or she needs to record it explicitly.

A design compromise made in to order to hit a deadline, be it an outright hack, or a decision made without time for rigorous investigation and testing, needs to be documented with the same rigor that one tracks a bug. What’s the best way to do this? Ideally, we’d have some kind of objective assessment of the level of technical debt in a software project, although that smacks of Science Fiction even as I write it. I’d be interested of hear of any methods you’ve used, but I’m sure most teams have to rely simply on the integrity of their colleagues and the clear perceptions of the project manager…



15 Responses to “Cheating on Technical Debt”

  1. callcopse says:

    I love the way you casually exemplify every project I have ever been passed (perhaps not all so bad but certainly to a notable extent). It’s a good way of describing the scenario and I’ll be thinking of how to bring this up so folks can be made to think about what compromises are inherent in the work they have done. I’d say in my own defence that I have always attempted to point out shortcomings when leaving projects for others to take on – and believe me, with the best will in the world there are always shortcomings. I have occasionally received the same courtesy myself. I’ll use the ideas here to be a little more explicit next time I hand over. To be fair I think my management have always accepted the shortcomings found in work passed on so I have not suffered excessively – but it is painful to me as a developer to spend so much time making projects work.

  2. Phil Factor says:

    There are still IT departments where developers spit when my name is mentioned, even though I’ve never intentionally committed this crime. This has happened where quick hacks that I’ve done to buy time until a permanent solution is purchased or developed have taken on an unintended life of their own. In one case, a long time ago, I wrote an automated deployment solution for a network of around 3000 PCs. The problem was that it was written as a command-shell script. It was hellish to maintain but Management decided that it should remain. Last time I inquired, it was still in place, despite the fact that Windows Server now does it all for you with a few mouse-clicks. I daren’t go near them for fear of retribution from embittered developers.

  3. DrTechnical says:

    I’ve alwasys believed that there are four kinds of solutions:

    1. Elegant, but not efficient
    2. Efficient, but not elegant
    3. Elegant AND effecient
    4. Neither elegant nor efficient

    I have always strived for elegant AND efficient, but I know I have not hit the mark as often as I would like. There is always the tendency to re-use code from an earlier solution that is known to work, without considering whether it should be re-analyzed to see if it is a good fit or could be done better.

    I do look for ways to improve my solutions. That’s what any good analyst does, and it SHOULD be second nature. And I want my solutions to be easily maintained (and easily understood) by those who may follow me. I’m happy to put my name on the program change log, and not afraid to document my involvement in the work that I do.

    That’s what a professional does.

  4. Keith Rowley says:

    The problem of course is that doing comprehensive documentation of every corner you cut adds significant time to the project, and if you had extra time you would not be cutting corners in the first place. ;-)

  5. SQL PROCtologist says:

    Like most everyone, I have given and received technical debt. It seems to be par for the course. As a perfectionist, I always strive for the best of the best solutions, but just as the Optimizer must choose a “good enough” plan, so too must I.
    With regard to knowingly cheating on technical debt, such activity would surely cause a BSOD.

  6. jkeefe says:

    Unfortunately, “technical debt” is only a euphemism for what’s really the issue: lack of accountability and insufficient oversight by supervisors and managers. I am in the process of inheriting a database from someone that is retiring from the company after 23 yearas of “we’ll document that later” and “we have to do this to get over the hump” and other sundry excuses for failing to perform the whole job. Now, on the way out the door at the end of the month, the retiring employee is “catching up” on comp-time by arriving late and leaving early every day with no regard for making up any of the deficit in the documentation. At this point I’d be happy to have a one-on-one with the soon-to0-be-departed just to quietly map out the areas where the greatest hidden deficits reside! It’s becoming clear that I’m going to be really busy for a really long time trying to straighten this mess out – luckily my management [obviously] doesn’t have a clue.

  7. Natarshia says:

    First I love simple talk from the stuff i learn. I’ve never heard of the term ‘technical debt’ until now, and then i looked it up (outside of the article, cause sometimes ppl make stuff up :) . So i’m like wow, i learned something new again ! But after 15 years in IT, of course I’ve left and gain technical debt. A while ago I decided to never bash someone’s code whether I knew the situation or the person, because I think i’m pretty good at my job, but what I don’t know is what hurts me, so maybe it was true of that person, and maybe the environment called for it. When I receive technical debt, I just make sure it’s clear to my superiors of what the code is supposed to do and let them know what it is or isn’t doing or how well it is or isn’t doing it. At that point, I feel all person technical debt is over, and my job is to get what they want me to get done based on priorities. I’ve learned not to take on extra debt, i.e, say i have to code or dba a new process. Well it’s from the current state, not some should be state. So the team or company has technical debt, but not me personally. Now I do as an employee try to make up for it, similar to a husband and wife helping each other out financially. And just like a couple, the best way to keep track is with a list (budget). It doesn’t have to be some super duper application, but a simple list. The project manager should be in charge of it, and simple mark , done, not done, partial with notes…. then anyone can look at the list and see what is or isn’t done. if you have big project and not doing this, well then you must have all the time and money in the world.

  8. Robert Young says:

    – This has happened where quick hacks that I’ve done to buy time until a permanent solution is purchased or developed have taken on an unintended life of their own.

    As the other Phil of my acquaintance always said, “never make a working PoC; it’ll be the delivered app.”

    As to lack of oversight: more now than ever, Suits don’t come up from Tech, but in from Marketing, or Accounting. They’re clueless, and proud of it.

    With RDBMS based applications, if your Up Lines denigrate Codd & RM & 3NF (“that’s all too theoretical; just write more code”), the Debt Level is guaranteed to accumulate.

  9. saran says:

    I am starting to love simpletalk. All the experiences over my career as DBA is documented and given a term.

    My experience is technical debt gets accumulated in the order of more to less by PM, developer , Infrastructure (DBA / Windows / Network). At the PM level those debt are spun out as additional features, at the developer level those are bug fixes and at the Infrastructure level, usually it results in performance issues

    Documentation usually is the first one to get hit and it should cover the larger size of the “technical debt” pie.

    I had myself added some of them over the years and I am now loading them on the next generation coming in, easily understood by the US Social security.

  10. paschott says:

    We’ve definitely had our share of technical debt in our current solution. It started off 10 years ago using the best tech of the time, but technology changes (especially if you’re a die-hard MS fan). So we have older code using one set of technology with minor issues and newer code that is significantly better. However, we have to balance adding new features against bringing that older code up to date when it pretty much works.

    We’ve had some freedom to address those older issues and made headway, but we can’t get everything done that we want without customers wondering when the improvements/enhancements will come. A lot of those changes behind the scenes were done to make it easier to maintain or perhaps slightly faster but added little to no new features so it’s not seen as valuable to the customers.

    Of course, sometimes we’ve had issues with poor decisions and cut corners to get things done or were perhaps overly optimistic in performance. I know at least a couple of my 10 year old solutions that were cobbled together are still in use at a former company. It’s good to know that they still work, but at the same time I wish they’d had time to do them right. At least I didn’t make the solutions hard to use or maintain.

    Currently, we eventually reach a point where we just need to address technical debt because it’s gotten too hard to maintain or out of hand. We have forgiving POs who have let us address those issues when they reach that state. We do have to make up for it later, though by letting some of those issues linger as we add new features. I can only imagine that it’s hard on the people making the decisions on addressing real underlying problems or adding new features.

  11. richierocks says:

    I think Jeff Atwood said it best:

    Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

  12. Dave.Poole says:

    The big problem is when those who agree to the tech debt never have to suffer the consequences of that decision.

    Think of Tech Debt as a payday loan. The interest is only bearable in the first 30 days.

  13. Robert Young says:


    Alas, it’s The Anointed Ones, those that move fast enough that incompetence never quite catches up, who leave behind the greatest debt. It’s almost as though Codd is looking down on us and saying, “Ha!”. They’re, as often as not, psychopathic in their own peculiar way.

  14. paschott says:

    I’d disagree with Dave’s point a little. We’ve had some really bad tech debt and people still here knew about it, but kept hoping that we’d get to re-write the entire area around that tech debt instead of little bits of it. They’ve stepped up to address what they could in the time allowed. It’s never quite enough, but when you’re trying to get new features delivered it’s sometimes hard to balance that good decision with speed.

    We’ve also dealt with some that was the result of too much forward planning – features that were discussed as if they were right around the corner, but never actually came to be. Sometimes we’ve dealt with unclear requirements as well – something that I wish we’d known _then_ what we know now. We built a ton of functionality and schema objects that were not actually needed because of the way the project was presented.

  15. rackorganizer01 says:

    Technical Analysis vs. Fundamental Analysis

    Most have heard of fundamental analysis (FA). In fact, it’s the stock market investing strategy that most are taught first. FA looks at things like earnings, cash flow, debt or any other financial aspect of a company, i.e., the “fundamentals” of a company. “Fundamentals” can also refer to economic fundamentals affecting the entire stock market. A person using FA might study financial statements to discover what he thinks a company’s stock should be worth, and then, if the stock is trading below that value, buy it hoping to make a future profit. In this way FA is a strategy concerned with the inner workings of companies.
    We have a organization name “Rack Organizer”.
    Our organization established in 1989, our core products are Cable Management, Copper Cat5E/Cat6 and Pre-terminated Fiber Cables.

Leave a Reply

Blog archive