Take a step back in history with the archives of PragPub magazine. The Pragmatic Programmers hope you’ll find that learning about the past can help you make better decisions for the future.

FROM THE ARCHIVES OF PRAGPUB MAGAZINE OCTOBER 2016

Johanna on Managing Product Development: Technical Debt and Other Unhelpful Euphemisms

By Johanna Rothman

6 min readOct 16, 2023

--

Calling your problems by their right names makes it much easier to solve them.

https://pragprog.com/newsletter/
https://pragprog.com/newsletter/

A manager asked me about technical debt. He started, We have test automation debt, both for system and unit tests. We have build system debt. We have technical debt everywhere. What should we do about it?

I asked him to explain more about the technical debt everywherepart of that sentence. I thought he had explained all the technical debt. No, there was more.

We have a bug database with a few thousand open bugs,he said.

Your product isnt that big or that old. Are you sure all of those problems are still open?I wanted clarification.

Well, I have no idea if all of them are still open. We havent tried to close things,he said.

He had identified insufficient test automation, insufficient build automation, customer-reported problems, team-found problems, and who knows what else in the bug database.

The first thing you should do is stop calling it by a name that is not correct.

When we take on debt in our personal lives, we make a conscious decision. We take out a mortgage or a loan, we review papers that tell us how much our debt will cost us over time, and then we sign papers saying we will pay back the debt.

The manager in question did not do that. The team did not do that.

They had no discussions in his organization about what their actions might mean later on.

Thats not debt. Thats taking shortcuts. It might be other things, too, and euphemisms prevent us from seeing what might be.

Insufficient Automation Is About Previous Shortcuts

When I speak with people like this, I often discover that they postponed automation in previous projects. Now that they want to use agile approaches, the postponed automation is a big problem.

In more plan-driven projects, the development becomes late for any number of reasons: requirements took too long, the architecture or analysis took too long, the developers encountered problems that took them longer to solve, and more. As a result, the development part of the project took longer than anyone expected.

Where does extratime come from in a project? At the end, the testing phase in a plan-driven project. We have all seen what happens then. The testers manually test, because they cant tell which tests they will have to repeat. Even if they repeat tests, it might take even more time to automate the tests.

And lets not even discuss the problem of hiring testers who cannot automate. Do not get me started on that.

Insufficient test automation is a result of insufficient risk management on the part of the project manager and the team members.

Everyone thought the the shortcuts might work for now. They could postpone all the lack of test automation into the next project and the next project and the next project.

Then they went agile, or tried to do so.

The shortcuts from previous projects became obvious. There could no longer postpone or ignore the automation work.

Insufficient Build Automation Is Cruft

When I spoke with the manager more, he explained that about five years ago, they had changed how they organized the system. That required build changes, but they did not complete the build changes. As a result, the build took longer, required more passes, and by now, required manual intervention.

I didnt ask how things got that way. Things get that way because its no ones job to manage the risks and create a streamlined build.

Even before they went agile, it took them close to three weeks to create a useful build. And that was with a dedicated build team. Yes, they had eight people whose job was to make the build right, and it took them three weeks to do so.

The slow build time created pent-up demand for fixes and features. The developers worked as fast as they could, continuing to take shortcuts. That created more defects, which the developers did not know about until much later when they had written the code and the defects.

Insufficient build automation is cruft. According to Wikipedia, cruft is jargon for anything that is left over, redundant, and getting in the way. It is used particularly for superseded and unused technical and electronic hardware and useless, superfluous, or dysfunctional elements in computer software.

When teams do not manage their internal tools, such as the build system, they become too busyto try to manage these tools. Its a vicious cycle, reinforcing itself.

And it creates problems and defects.

Bugs Are Problems or Defects

The original bug was a moth in the wiring of a computer. We rarely have moths or insects in our code or computers now. Why do we still refer to problems or defects as bugs?

We refer to them as bugs because then we dont have to admit we were wrong.

For many of us, its difficult to ask for help, but we also find it difficult to admit when we are wrong. Ive been practicing. For me, its getting easier to admit when I was wrong. But my first inclination is to deny it.

When we use a term such as bug, we get to deny that we put it there. But lets face it: If we write code, we also write defects. This includes testers who write test automation.

People who write code write defects.

When we release those defects to the customer, they report problems. Sometimes, loudly.

When I started calling my bugs defects and my escaped defects problems, those names changed the way I thought about my work. I didnt want defects. Clearly, I had a hand in creating those defects.

I didnt want my customers reporting problems in my products. When I changed from using the word bug to using the word problem, it changed my perspective.

Bugs arrive because insects will rule us all, at some point. We cant do anything about bugs. Instead, in the process of creating, we create defects and problems. But we can fix them, too.

Language Can Drive Our Behavior

When I stopped lumping everything as technical debt of some variety, and instead used the correct words: shortcuts, cruft, problems, and defects, my code and projects got better. Its not that the language made them better. Its that the new language didnt let me hide from decisions. The new language helped me change my actions to prevent shortcuts, cruft, problems, and defects.

If we, as a project team, decide to take a shortcut, that looks a lot like real technical debt. We discuss the shortcut, discuss the implications, and make a conscious decision.

Consider changing how you name your project problems. If you have not consciously decided on a specific action, dont call it technical debt. Call it a shortcut, cruft, problem, or defect. Or, decide on a name that fits your particular environment.

Make technical debt a conscious decision whether or not you are agile. Dont let euphemisms drive your work.

About the Author

Johanna Rothman’s latest book is called Successful Independent Consulting, and is available from The Pragmatic Bookshelf.

magazine cover showing woman with a camera in b&w
Cover of PragPub Magazine, October 2016

--

--

PragPub
The Pragmatic Programmers

The Pragmatic Programmers bring you archives from PragPub, a magazine on web and mobile development (by editor Michael Swaine, of Dr. Dobb’s Journal fame).