DaedTech

Stories about Software

By

The One Thing Every Company Can Do to Reduce Technical Debt

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at the technical debt functionality in the latest version of NDepend.

The idea of technical debt has become ubiquitous in our industry.  It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code.  Then, from there, it grew to define perhaps the foundational of tradeoffs in the tech world.

You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt.  It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning.  “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”

As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more.  Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it.  And so shops constantly grapple with the question, “how can we reduce our tech debt?”

I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt.  First, I’d tell you to reduce problematic coupling.  Then, I’d tell you to stop it with the global variables.  You get the idea.

But today, I want to do something a bit different.  I want to talk about the one thing that every company can do to reduce tech debt.  I consider it to be sort of a step zero.

The Tale of the Absent Product Owner

But before I go for the big reveal, I’d like to veer into a bit of a parable.  Don’t worry — I’ll try to make this at least nominally entertaining via the art of the narrative.

Once upon a time, during my travels as an IT management consultant, I encountered a team looking to improve its throughput.  Okay that might describe every team I work with, so I’ll get a bit more specific.  This team wanted to improve throughput, but found itself stuck when it couldn’t get answers to clarifying questions about the business quickly enough.  “Should we consider user submitting an invalid form an error state, or do we expect that?”  Crickets.

This team had “gone agile” at some point.  From there, they worked their way into a comfort zone with this new reality, adapting to the roles and ceremonies of a Scrum team.  One such role, the product owner, serves to represent the business to the team.  But with this particular team, the product owner seemed in a constant state of attending meetings in other locations, away from the team.

How did they fix this?  Meetings?  Interventions from on high?  Pleading?  Nope.  They went more low tech and simpler.  They simply started writing on a big white board, “number of hours with access to the product owner today” followed by the count.  The whole department could then see that this team had access to its product owner for 0 or 1 hours.  With no other interventions whatsoever, the number increased significantly within a matter of weeks.

Sunlight is the Best Disinfectant

I had no shortage of management consulting cliches from which to pick for this section’s header, but I went with words of Louis Brandeis.  I just like the ring of it.

Sunlight makes the best disinfectant.  This colorfully illustrates the notion that simply illuminating problems can make them go away.  In this case, calling the product owner’s (and everyone else’s) attention to his rampant absenteeism inspired him to address the problem without further prompting.  You have probably experienced a phenomenon like this in your personal life.  For instance, perhaps just the act of weighing yourself every day makes you lose a bit of weight, simply by virtue of putting the effects of your eating choices in the front of your mind.

Generally speaking, focusing the spotlight on something can, in and of itself, alter the thing you’re looking at.  We might borrow from physics and think of this as “observer effect.”  It packs a powerful punch as a recommendation because of both its inevitability and potential healing power.  If you want to improve something with any efficacy, you must first start measuring it so that you have a benchmark.

Thus shining light on something represents a possible improvement strategy in and of itself, as well as a first step ahead of other interventions.  It is for this reason that I think of measurement as “step zero.”

Back to the Topic of Tech Debt

The recent release of NDepend reminded me of this question that organizations often ask me about tech debt.  They want to know the single best approach for mitigation, and NDepend’s new release offers it in spades.

Simply put, you can best fight tech debt by visibly measuring it.    Do you need to get the exact number of hours or dollars spent on employee labor completely correct?  No, of course not.  Don’t get too hung up on that.

Just go put a figure to it so that you can watch that figure change as you do your work.  I cannot overstate the importance of this.  If you wring your hands over the particulars, your tech debt will remain forever unquantified and thus abstract.  If you say, “we have a lot of tech debt,” business stakeholders will answer, “so does every place I’ve ever worked — whatever.”

But if you write up on the big board that you have 225 days of tech debt when yesterday’s figure had only 200, people are going to notice.  Discussions will start.  Suddenly, the tech debt becomes everyone’s problem.  And, once that happens, watch as the number starts to decrease as if of its own volition.

7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Vince Bullinger
Vince Bullinger
7 years ago

Great point and definitely something I’ve figured out, without codifying it so succinctly.

Peter Morlion
7 years ago

Totally agree on making issues visible. I would like some more opinion on the story about the PO though. I’m currently Scrummaster and developer on a team and would hesitate on doing that (writing PO hours on the wall), because it seems like public shaming. It could create an atmosphere of enmity (team vs PO), don’t you think?

Phil
7 years ago
Reply to  Peter Morlion

I’d wager a guess that the enmity was already there before it was put out in the open. But as a devil’s advocate, I’d also say it should be dealt with during retrospective, no? Ahhh how the spirits of Agile haunt us!

Peter Morlion
7 years ago
Reply to  Phil

Good point. Although it might be neither enmity nor team-spirit that is present. And when you’re still building a team, I’d personally be prudent with such measures. Only when you know the targeted person will be open to such an initiative should you start with it. My opinion of course.

Peter Morlion
7 years ago
Reply to  Erik Dietrich

That I like. The fact that it was discussed and agreed on.