{"id":678,"date":"2016-06-29T06:26:00","date_gmt":"2016-06-29T06:26:00","guid":{"rendered":"https:\/\/staging.infragistics.com\/blogs\/?p=678"},"modified":"2025-02-26T12:08:12","modified_gmt":"2025-02-26T12:08:12","slug":"the-human-cost-of-tech-debt","status":"publish","type":"post","link":"https:\/\/www.infragistics.com\/blogs\/the-human-cost-of-tech-debt","title":{"rendered":"The Human Cost of Tech Debt"},"content":{"rendered":"\n

Coined by\u00a0Ward 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. \u00a0In 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.<\/p>\n\n\n\n

If you’re not already familiar with the concept of\u00a0technical debt<\/a>, it’s worth becoming familiar with it. \u00a0I say this not only because it is a common industry term, but because it is an important concept.<\/p>\n\n\n\n

\"human<\/figure>\n\n\n\n

The Power of the Metaphor<\/h2>\n\n\n\n

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<\/i> 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.<\/i><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The problem of technical debt is for most people, in essence, a problem of time to market.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Unpleasant Work<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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<\/i>, which is, in turn, demoralizing.<\/p>\n\n\n\n

Team Infighting<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Atrophied Skills<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

In these sorts of codebases, everything becomes difficult<\/i>.  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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The Hidden Business Cost: Turnover and Attrition<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Is There a Solution?<\/h2>\n\n\n\n

Now, there is a better and more efficient way to try to tackle all this – with the help of low-code drag and drop App BuilderTM<\/sup><\/a>. You can learn all about it and even how to reduce cost during a recession by reading the following blog post:<\/p>\n\n\n\n

What Is Low-Code Process Automation & How Can Your Business Benefit from It?<\/a><\/p>\n\n\n\n

\"low-code<\/a><\/figure>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Coined by\u00a0Ward 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. \u00a0In 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.<\/p>\n","protected":false},"author":21,"featured_media":2370,"comment_status":"publish","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17],"tags":[],"class_list":["post-678","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to"],"_links":{"self":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/678","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/comments?post=678"}],"version-history":[{"count":3,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/678\/revisions"}],"predecessor-version":[{"id":2511,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/678\/revisions\/2511"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media\/2370"}],"wp:attachment":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media?parent=678"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/categories?post=678"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/tags?post=678"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}