FROM THE ARCHIVES OF PRAGPUB MAGAZINE OCTOBER 2016
Johanna on Managing Product Development: Technical Debt and Other Unhelpful Euphemisms
By Johanna Rothman
Calling your problems by their right names makes it much easier to solve them.
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 everywhere” part 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 isn’t 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 haven’t 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.
That’s not debt. That’s 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 “extra” time 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 can’t tell which tests they will have to repeat. Even if they repeat tests, it might take even more time to automate the tests.
And let’s 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 didn’t ask how things got that way. Things get that way because it’s no one’s 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 busy” to try to manage these tools. It’s 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 don’t have to admit we were wrong.
For many of us, it’s difficult to ask for help, but we also find it difficult to admit when we are wrong. I’ve been practicing. For me, it’s 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 let’s 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 didn’t want defects. Clearly, I had a hand in creating those defects.
I didn’t 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 can’t 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. It’s not that the language made them better. It’s that the new language didn’t 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, don’t 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. Don’t 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.
