The Human Side of Technical Debt

by

Technical debt has not only become a popular industry term, but it has proven itself to be an important concept. It was developed to discuss the idea that taking short cuts in your software now, will not only mean having to pay back that cost in the future but paying it back with interest. That means that if you took a particular short cut today that saved you half a day's work, you will have to pay it back with more than half a day's work in the future.

Using this metaphor relating to financial debt is extremely powerful because of the way it can enable communication between non-technical business stakeholders and those working directly with software development. Using the language of finance with those business stakeholders will help them to understand the problems that developers face when building software in a way that would otherwise be more difficult and less feasible.

Due to the way in which the term is so effective in communicating developer concerns in a business mindset it is often used to explain how certain deadlines or milestones can actually be detrimental in the future due to their tendency to accrue technical debt. If you are faced with a stringent deadline that will most likely result in technical debt and make new features take longer to ship in the future, you can express this to business stakeholders to explain the need to extend deadlines or explain delays.

Technical debt, for most, is an adept way to explain the problems of time to market. In this post, however, we discuss the human side of the problem. And as is very astutely mentioned in this post, all human problems are also business problems if you look at it through the right mindset. This human side to technical debt is sorely, rarely discussed.

For a project manager, working with high levels of technical debt means slow delivery and frustration when discussing a projects capability and business value. But for those working directly on the code, a developer for instance, this frustration is even stronger. For a developer working on a project bogged down with technical debt it can feel like you are being unproductive day in and day out.

Knowing that you will spend the better part of day trying to work out something simple and have to persistently explain why such a simple task is taking a long time is disastrous for team morale. And when new developers or consultants are brought in to help having to face their confusion and contempt with having to work on debt ridden code will only worsen the problem.

It’s similar to having large personal amounts of debt and having to explain why you have creditors on your tail - it is embarrassing and exhausting.

If you are part of a team that has to work everyday on debt ridden code is also likely to cause team infighting because tension is high and morale is low. Again, this is similar to a married couple who has to deal with crippling debt between them. It could manifest itself as new developers blaming existing staff for creating a problem they now have to deal with. Asides from the problem of technical debt affecting the quality and sustainability of a software project it will also start to infect the ability of team to function interpersonally, and eventually their ability to continue doing the job they were meant to do properly.

Just as technical debt wreaks havoc on a code base by making each iteration more difficult and less effective, team members will begin to feel the downward spiral of technical debt. Not only with their difficulty of working as a team, but with how it effects their professional lives by continually having put off updating and improving the software they are working on, and in turn delaying the update of their skills. In the end, with enough technical debt, everything becomes difficult.

So what does the human side of technical debt actually cost? It should become obvious from this post that the happiness of developers invariably cost management in productivity, but it will cost them in turn over as well. Those developers that lead the charge in leaving an organization will be those that you can’t afford to lose.

Thinking of technical debt as only costing in terms of delayed deadlines and increase defect counts is a narrow view. The human cost of it will be more detrimental and cause many more business problems in the long run.

To read more visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|