Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Technical Debt: I Do Not Think It Means What You Think It Means

DZone's Guide to

Technical Debt: I Do Not Think It Means What You Think It Means

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Here’s another example of why language matters, and how the words we choose matter so much.

I tried to join the European Lean-Kanban tour, not in person, but on twitter. (By the way, seems like an awesome tour, I’m thinking about going there next time around). And then the following tweet comes up:

"@cyetain: Talking to @DReinertsen at #lkfr12 he prefers "Deferred Work" to Tech Debt Metaphor. I think it is a bit clearer too..."

Before I give my interpretation, I give thanks to Jabe Bloom, who tweeted like crazy and made me feel at home (online) and for reporting this tweet (and giving birth to this blog post by proxy:)). And Don Reinertsen, I’m gaining more respect for everyday.

Now that the niceties are out of the way…

Technical Debt or Deferred Work?

When developers talk about technical debt, the words say: There’s some technical stuff we left out, which will come back to bite us. The refactoring we didn’t do will cost us when we’ll enhance that feature. Those tests we skipped writing, are going to cost us in regression bugs.

Note the economic jargon: The debt is an economic one, NOT technical. That’s no coincidence. Economics is a better way to persuade managers to listen to developers.

There’s also an emotional nuance in the term. When we’re taking on technical debt, we, developers, are carrying the cross for the company. Not only that, we take the blame, and know we’ll pay the price later. Or we can translate it to: We’re warning you, managers, this “joint” decision is on your head.

From the manager’s side, things look much clearer: We’re always prioritizing stuff. We can’t do everything we want, and things get dropped. So in the upcoming release, we’re going to drop these pesky technical things we don’t really understand. We do understand there are associated costs and risks (as the developers tried to explain), and we’re ready to decide.

We’re really deferring work. This is a business decision.

Not Just Words

Agile started as a solution to a problem: building a bridge between developers and the business people. The bridge is built on trust. Trust is built on communication. When we use charged words on one side, or disregard this emotional charge from the other side, we’re adding cracks to the bridge.

A few cracks will not break the bridge.

What do you think happens when there are many of them?

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}