DaedTech

Stories about Software

By

The Human Cost of Tech Debt

Editorial Note: I originally wrote this post for the Infragistics blog.  Head over to their site and check out the original.  While you’re there, have a look at the other blog authors and their product offering.

If you’re not already familiar with the concept of technical debt, it’s worth becoming familiar with it.  I say this not only because it is a common industry term, but because it is an important concept.

Coined by Ward Cunningham, the term introduces the idea that taking shortcuts in your software today not only means paying the price eventually — it means paying that price with interest.  In other words, introducing that global variable today and saving half a day’s work ahead of shipping means that you’re going to pay for it with more than half a day’s labor down the line.

Man holding heavy chest

The Power of the Metaphor

I’ve spent significant time doing IT management consulting in recent years, after spending years and years writing code.  And I can tell you that this metaphor for shortcuts in the codebase is a powerful one when it comes to communication between the business and the software development group.  When you explain software decisions to managers and MBAs using the language of economics, they get it.

Because of the metaphor’s power and subsequent effectiveness for business concerns, it is often used to describe the health of projects, particularly vis a vis deadlines and milestones.  The developers may communicate that an aggressive deadline will result in technical debt, making features in the future take longer to ship.  Analysts and project managers might account for technical debt when discussing slipped deadlines.  IT upper management might ask for an assessment of the amount of technical in an application when making a strategic, replace/retire/rewrite decision.

The problem of technical debt is for most people, in essence, a problem of time to market.

But I’d like to talk today about the human side of the problem.  And, make no mistake — in business, all human problems are also business problems,viewed with a wide enough lens.  Unhappy humans are unhappy workers, and unhappy workers are less productive.  Yet, this angle of technical debt is seldom discussed, in my experience.

Unpleasant Work

For a manager, a code base high in technical debt means that feature delivery slows to a crawl, which creates a lot of frustration and awkward moments in conversation about business capability.  For a developer, this frustration is even more acute.   Nobody likes working with a significant handicap and being unproductive day after day, and that is exactly what this sort of codebase means for developers.

Each day they go to the office knowing that it’s going to take the better part of a day to do something simple like add a checkbox to a form.  They know that they’re going to have to manufacture endless explanations for why seemingly simple things take them a long time.  When new developers are hired or consultants brought in, they know that they’re going to have to face confused looks, followed by those newbies trying to hide mild contempt.

To tie this back to the tech debt metaphor, think of someone with mountains of debt trying to explain being harassed by creditors.  It’s embarrassing, which is, in turn, demoralizing.

Team Infighting

Not surprisingly, this kind of situation tends to lead to bickering among the team.  Again, the metaphor holds as one would expect this kind of behavior from a married couple with crippling debt.  Teams draw battle lines.

It might be the aforementioned newbies against the tenured staff upon whom they blame the problem.  It might be the maintenance programmers versus the developers or the people on the green field project versus the people responsible for the legacy beast in which the tech debt resides.

Whatever those lines may be, they become real and they become problematic.  They add acrimony on top of the frustration and embarrassment of the problem itself.

Atrophied Skills

As embarrassment mounts and the blame game is played more vigorously, team members can feel their professional relevance slipping away.  After all, tech debt creates substantial drag not only on feature development, but on the general evolution of a codebase.

In these sorts of codebases, everything becomes difficult.  Teams postpone upgrading to the latest version of the language.  They resist incorporating modern architectural and design practices.  They fear to replace outdated third party add-ins with modern ones.  Generally speaking, they want to touch things as little as humanly possible, because doing so further impairs their already lethargic process.  It’s too slow and it’s too risky.

But even as they make these decisions (or at least live with them when others make them), they understand that their market value is waning with each passing day.  It is not lost on them that while the wide development world embraces the newest javascript frameworks and domain driven design approaches, they’re struggling to add features to a wheezy, CRUD-based, Winforms application.

The Hidden Business Cost: Turnover and Attrition

Hopefully it should be obvious to management that unhappy developers is a business problem and a serious one at that.  In the current IT market climate, developers have options — even ones stuck on a legacy codebase with crippling tech debt.

Coming to work each day to work in a tortured code base, with disgruntled people, and with a mounting sense of irrelevance creates a team full of people that are going to be open to other options.  And, sooner or later, they’re going to start leaving, and the ones leading the charge will be the ones the organization can least afford to lose.  It will become harder and harder to hire into the group and it will take longer and longer for those who do come in to be productive.

So when you think of tech debt, don’t think only in terms of the business problem of delayed features and rising defect counts.  Think of the human cost, and the much more serious, much longer term business problem that results.

Editorial Note: This post was later referenced here, at DevIQ.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

53 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Noam
Noam
7 years ago

Well written and very interesting.

Erik Dietrich
7 years ago
Reply to  Noam

Thanks for the feedback!

Przemek
Przemek
7 years ago

Nice one. That’s exactlly what comes to my mind when I hear managers saying they can’t afford spending half of a realease/few weeks/days for upgrading a framework, tool which is essential for the project because it has no business value. It does! But an implicit one. Not mentioning the fact that old versions get abandoned at some point 😉

Erik Dietrich
7 years ago
Reply to  Przemek

I’ve been doing a lot of IT/Dev management consulting over the last few years, and I find that I spend a lot of time trying to surface things like this. So many companies overlook this type of concern and then are mystified when their average developer turnover is a year or why they can’t get people to come work for them.

MaxArt
MaxArt
7 years ago

Sadly, I’ve been there, part of machine that I wasn’t allowed to have any control over. In that case, sheer incompetence about modern development ways paved the path of technical debt. The symptoms were so clear.
Lesson learned. Now that I’ve moved to much greener pastures, I’m continuously watching over the risk of technical debt.

Erik Dietrich
7 years ago
Reply to  MaxArt

I can totally relate, and it seems that a lot of others can as well. For organizations, the risk of attrition is a serious one with developers in such high demand.

Amused Norn
Amused Norn
7 years ago

I’m weird. I kind of enjoy grovelling over old stuff and bringing it in line with current standards and practices, finding the literals that should be variables, and the variables that should be constants. I should probably figure out how to put that in the CV…

datguy
datguy
7 years ago
Reply to  Amused Norn

Refactoring can be pleasant yes. The pain mostly comes from being pushed to ship features with no time for refactoring.

Even then you might decide at some point “oh I’ll just refactor this small thing” while building a new feature but you realize after a few hours in that this small refactor ends up needing much more work to get back in a working state and meanwhile you think about the task you had estimated that you are not getting done.

Erik Dietrich
7 years ago
Reply to  Amused Norn

I think there’s a surprising number of people who feel this way (me being one of them). There’s a sense of putting order to an disordered situation that satisfies.

Mildo
Mildo
7 years ago
Reply to  Amused Norn

I think it’s not weird as there is many people who enjoy it the same way, including me. Recently I have been entitled to refactor our whole codebase and I am so happy for that as the pain of working with (or even looking at) old poorly written code was getting unbearable…

Rajesh Rao
Rajesh Rao
7 years ago

Great article Erik. Although I loved that you are talking about a very bold topic, but it would have been great if you could explain how teams & organizations can solve this technical debt. From my experience, I have worked in team & know customers who know their code base is old and developers are not happy maintaining it but nobody has an immediate solution to it. How do you get out of such situation? My second point is that, many a times people are unaware while they are adding to technical debt. Agile & Scrum play a big portion… Read more »

Erik Dietrich
7 years ago
Reply to  Rajesh Rao

Wow, “how to fix it” and “what creates it” are two extremely deep topics that I’d like to delve into. I keep a backlog of questions that readers submit, and I’m going to add both of these to that backlog. Stay tuned to the blog if you’d like to see my take in a future post.

And, thanks for the comment — it’s always nice to get ideas for interesting topics.

Simon Tarry
Simon Tarry
7 years ago
Reply to  Rajesh Rao

@Raj@disqus_rhHgkVyOC6:disqus At Ticketmaster we tackled this by turning it from a technical problem to a business problem: https://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/

nithin nambiar
nithin nambiar
7 years ago
Reply to  Simon Tarry

i agree, hard to get budget for reducing technical debts unless you can find a business justification for it.

MichaelOChurch
MichaelOChurch
7 years ago

This is all true, and I think it’s also worth pointing out that technical “debt” is a bad metaphor. Debt has a known interest rate that might be on the order of 5 percent per year. Technical debt’s interest rate is unpredictable and extremely high. Credit card debt isn’t the best kind to have, but it doesn’t randomly blow your face off either.

johnstrickler
johnstrickler
7 years ago
Reply to  MichaelOChurch

Technical debt relates closer to debt acquired by your local loan shark. Of course it has a steep interest rate but it can be called in for full payment at any time.

Erik Dietrich
7 years ago
Reply to  MichaelOChurch

I’ve often thought about this in the context of the unknown interest rate. I can recall explaining to someone, that technical debt would be akin to a deal where you incur a credit card debt, but with no payoff schedule and an interest rate that is opaque to you and varies between 0 and hundreds of percent each day.

caente
7 years ago

> Analysts and project managers might account for technical debt when discussing slipped deadlines. No they won’t, you cannot quantify technical debt, it’s a *metaphor*. I completely agree with the rest of the post. But “technical debt” is not a cause, nor a valid metaphor to share with management. Other bad metaphors are: “building” and “architecture”. We are not building anything, we are only writing algorithms that computers will follow. When we write down those algorithms, we are also encoding the inner workings of the company. The true knowledge of how a company works is not only in their papers… Read more »

Andy Henry
Andy Henry
7 years ago
Reply to  caente

Great comments. Even if you explain these concepts to managers it doesn’t change things because getting things done quickly is usually the primary driver for code releases and they will happily kick the can down the road while they don’t feel the pain, and often blame engineering when it finally does come home to roost and development slows. What’s needed is strong engineering leadership that supports fundamental core quality and knows when to let the developers have the time they need. It’s not a one-sided issue though, developers often struggle to settle for ‘good enough’ and prefer to keep fiddling… Read more »

Erik Dietrich
7 years ago
Reply to  caente

I’m inclined to agree with you on the count of the building metaphor (and I’ve ranted about this more than once in years past on this blog: https://daedtech.com/a-metaphor-to-help-you-suck-at-writing-software/ ) But I’d argue that “technical debt” is a better metaphor than building construction in the sense that it does less harm with false parallels. True, it is not a perfect metaphor by any stretch (e.g. Michael O. Church’s point about unknowable interest rates), but I personally think it is a helpful one whereas the building metaphor is so flawed as to do more harm than good. I’m not sure I understand… Read more »

caente
7 years ago
Reply to  Erik Dietrich

> I see technical debt the same way. “If we do this now, you’re going to pay it back with interest later.” yes but that metaphor lacks a very important “detail” associated with debt: How much? There are debts that you would take because the amount is not too dangerous. How can management know when it’s OK to take the debt? They need to trust eng, and if they trust eng, then why do we need the metaphor? If there is not enough trust, you’ll end up depending on the ability of the eng to scare management versus the capacity… Read more »

Erik Dietrich
7 years ago
Reply to  caente

Oh, I see what I was misunderstanding about your point. In my original post, when I was talking about management accounting for technical debt, I wasn’t meaning that they could essentially do so with some kind of tool or pseudo-analytical equation about the code. I meant in a qualitative sense. They could account for it in their planning or post mortems, meaning that if the developers told them that tech debt was making a deadline unlikely, they could change the business’s plan, cut scope, or whatever. I could not agree more about management needing to trust the developers (i.e. the… Read more »

caente
7 years ago
Reply to  Erik Dietrich

hehehe, basically an “I told you so” tool? I like it!

Dom Barker
Dom Barker
7 years ago

Great article. I think the situations described here result when teams default on their technical debt. I’d argue that not all technical debt is bad, and even then, it’s not always possible to avoid it anyway. Here’s some more detail: https://medium.com/@MostlyHarmlessD/on-technical-debt-7bac65edf349

Erik Dietrich
7 years ago
Reply to  Dom Barker

Thanks! I’ve seen people in the past draw the distinction between deliberate and accidental technical debt, the latter of which could be argued generally to be bad. The former, though, could certainly be positioned as simply a business decision with pros and cons.

In your post you mention a technical credit score. Have you ever put a score to the amount of tech debt in a codebase (or used a tool that did)?

Tracy Singleton
Tracy Singleton
7 years ago

Great article and spot on!

Erik Dietrich
7 years ago

Thanks! I’m glad you liked it.

Bharat Meda
Bharat Meda
7 years ago

This perspective is probably the most ignored… great insight!

Grant Winney
7 years ago

As usual, great article Erik! I worked somewhere where I liked the team, but the project was a decade old and parts of it were buried under a mountain of technical debt. So much in this piece resonated with me. Embarrassment at how long simple things took to implement, and the part I played in it. Frustration at those who came before me, or who came after, wrote a quick piece of code destined for debt, and then left. Ultimately, the realization I was working in a legacy app with a legacy codebase and little chance of digging out unless… Read more »

Erik Dietrich
7 years ago
Reply to  Grant Winney

Thanks — I’m glad if it struck a chord. And, I’ve been there with you, FWIW.

indyk
indyk
7 years ago

> Yes, this angle of technical debt is seldom discussed, in my experience.
can not shake the feeling that “Yes” should have been “Yet”

Erik Dietrich
7 years ago
Reply to  indyk

You’re right about that. Fixed — thanks!

Bud Goode
Bud Goode
7 years ago

“Analysts and project managers might account for technical debt when discussing slipped deadlines.” The operative word there is “might”. Unfortunately, most don’t account for technical debt when dealing with deadlines (after all, how do you think the technical debt got there in the first place?) The business problem here is a much wider one. It’s simply a case of “the now” trumping “the future”. Most companies don’t measure (for example) performance on how things could be in 1 or 2 years time, they’ll measure those managers on their performance for *this quarter*, hence no one will care about how crippling… Read more »

Scott Lynch
Scott Lynch
7 years ago

Thanks for writing this article. People (especially management) often overlook the impact bad code has on an organization from a employee satisfaction perspective. I’m living this currently (and for the past 2 years) on a code base that is over a decade old. I’ve been developing software for a long time (25 years) and this code base is the worst I’ve ever worked on. Refactoring is one of my strengths, however this code is so laden with debt as to be untouchable without serious ramifications (more bugs and lost revenue). Sadly the culture here has devolved into one of “touch… Read more »

Zachary Burnham
Zachary Burnham
7 years ago
Reply to  Scott Lynch

I don’t think they’re overlooking it. I think they don’t care about employee satisfaction, which is difficult to measure, can’t be directly correlated to profitability, and requires resources to improve. The only things management cares about are increasing revenues and lowering costs; keeping employee expenses (salaries/benefits/general humane treatment) to an absolute minimum. Their attitude is that if you don’t like what you’re doing, there’s the door, we’ll hire someone younger and cheaper than you (conveniently ignoring the fact that keeping an employee is much less expensive than hiring a new one).

Kirk Halgren
Kirk Halgren
7 years ago

Another metaphor I like is that when building a doghouse, one can be very casual about design: there are very few requirements and no building code, with an easily pleased client. On the other hand, creating a skyscraper involves much more planning and documentation. A big factor in this problem is how many managers have never done any development work in their entire careers. I used to regularly curse the Microsoft developers whose bugs and wildly inconsistent UI “designs” waste too much of my time and focus, but a month or two back I realized that those unfortunate souls not… Read more »

Lorenzo Solano
Lorenzo Solano
7 years ago

Very good angle for this so common problem.

Oliver Godby
Oliver Godby
7 years ago

This is very perceptive and well considered and is in line with thoughts that I haev been having over the last couple of years. I am absolutely going to bookmark this and send it to everyone I know. Thanks!

Erik Dietrich
7 years ago
Reply to  Oliver Godby

Thanks for the kind words, and for the referrals!

Dave
7 years ago

After 7 months of hard work (full time without pay :() I’m proud to announce the Soft launch of WeDoTDD.com – A list of companies practicing TDD! Just as promised. More companies to be added to it soon and ongoing into infinity.

Carlos Vitor Barros
Carlos Vitor Barros
7 years ago

Excellent point of view, thanks for sharing this!

Kevin Newsom
Kevin Newsom
7 years ago

I liked this and I think it is true. However, I haven’t seen an organization yet that has valued code quality the same as schedule (delivery dates). The incessant pressure of ‘why isn’t this done yet?’ trumps all in our field. One of the better attempts to solve this problem is with Robert Martin’s talk ‘Are We Professionals’ https://www.youtube.com/watch?v=p0O1VVqRSK0.

Bartlomiej Filipek
7 years ago

you’ve wrapped that perfectly! Adding a simple UI control that takes you a whole day… been there as well.

When reading your post I’ve remembered about article from Bart Wronski about technical Weight. Where your decisions make software more and more complex, harder to understand, debug… work with:
https://bartwronski.com/2016/06/26/technical-weight/
Like when you have a really complex algorithm/subsystem that’s core part of the app. No one wants to touch it because it might be so fragile.

Erik Dietrich
7 years ago

That post makes me think of the distinction between essential complexity versus accidental complexity. Sounds like he’s talking about essential complexity.

Allan
Allan
7 years ago

I’ve worked in two companies who have decided to use Plone as their CMS system. I can relate to this 100% on point unfotunately.

REMI GOYARD
REMI GOYARD
7 years ago

Very interesting ! Thank for your post !

Marcelo Lv Cabral
7 years ago

Nice article! I just recorded an episode of my podcast (in portuguese) commenting tech debt and we talked about your article (linked also in the show notes).

http://www.podebug.com/2016/09/030-qualidade-de-software-seja-um-programador-lannister/

PS. The translation of the title is:
“Software Quality: Be a Lannister Programmer”
Only GOT fans can take the joke 🙂

Erik Dietrich
7 years ago

Thanks for the mention! And, I read all of the GOT books, so I get the reference. 🙂 I like it.

shashikant fayke
shashikant fayke
7 years ago

Well written and deep insight

Erik Dietrich
7 years ago

Thanks!

Żukoteka
7 years ago

Battles among people about tech debt is mostly in scheme business vs tech. It is because business does not understand this whole ‘fuss’ about tech debt.

Dave Fenton
Dave Fenton
6 years ago

Great article, really hits the nail on the head.
Pinged it around everyone here where I work.

I just wish I’d written it! 🙂