4   Damn the Torpedoes, Go Ahead

“When you discover a problem in someone else’s code, just keep it to yourself. After all, you wouldn’t want to hurt their feelings or cause trouble. And if that someone else happens to be your boss, be extra careful, and just follow orders.”

In the fable “Who Will Bell the Cat?” the mice decide to tie a bell around the neck of the cat so they’d receive advance warning when the cat was on the prowl. Every mouse agrees that this is an excellent plan. The old mouse asks, “So, who will volunteer to tie on the bell?” Not surprisingly, no mouse stepped forward, and the plan was dropped.

Sometimes the best plans fail in the absence of courage. Despite the dangers—the real and metaphorical torpedoes—you need to charge ahead and do what’s right.

You’ve just been asked to fix some code written by someone else. The code is very hard to understand and work with. Should you continue to work with it, leaving it in a mess at the end? Or should you tell the boss that the code sucks and should be thrown away?

Maybe it’s cathartic to stomp around telling everyone how bad the code is, but that’s just complaining, not working on a solution. Instead, present the pros and cons of working with the code versus rewriting it. Show—don’t just tell—that it’s more cost effective to throw the code away and rewrite it. Present reasons that will help your boss (and colleagues) evaluate the situation, helping them come to the correct solution.

Now suppose you’ve been working on a particular component for a while. Suddenly you realize that you’ve been climbing the wrong tree; you really should redo your work. Naturally, you’re worried about confessing the problem to the rest of your team and asking for more time or for help.

Venkat says:

Enforce Good Practices

I was working with an application that sends different types of files to a server process and was asked to implement code to save another type of file. That shouldn’t be hard. When I started digging in, I was shocked to find that the code to handle each type of file was duplicated. So I followed suit: I copied and pasted a hundred lines of code, changed two lines in it, and got it working in minutes—but I felt low. I had violated good working practices.

I convinced the boss that the code would quickly become too expensive to maintain and should be refactored. Within a week, we saw the benefit of that effort when we had to make some changes to how files were handled—only now, the change was contained to one place instead of spread all over the system.

Rather than trying to cover up the issue, stand up and say, “I now realize that what I’ve done is not the right approach. Here are some of the ways I thought of to fix it—if you have more ideas, I’d like to hear about them—but it’s going to take more time.” You have removed all heat out of the issue and clearly indicated that you’re interested in finding a solution. You have asked people to work with you on a solution—there’s no place for rebuttal. Your team will be motivated to work with you in solving the problem. They may step in and give you a hand. What’s more, you’ve shown your honesty and courage—you’ve earned their trust.

You know the right thing that needs to be done—or at least that the current way is wrong. Have courage to explain your view to the rest of the team, your boss, or the client. That’s not always easy, of course. It may be that this will make the project late, offend the project manager, or annoy the sponsors. You need to press forward and take the correct approach regardless.

It was Civil War Admiral David Farragut who famously said, “Damn the torpedoes! Captain Drayton, go ahead! Jouett, full speed!” Yes, there were mines in the way (called torpedoes at the time), but they had to get through, so full speed ahead they went.^[5]

It was the right thing to do.

Do what’s right. Be honest, and have the courage to communicate the truth. It may be difficult at times; that’s why it takes courage.

What It Feels Like

Courage doesn’t feel very comfortable, certainly not ahead of time. But it’s often the only way to remove obstacles that will just grow worse over time, and you’ll feel relief instead of increasing dread.

Keeping Your Balance

• If you think the sky is falling and the rest of the team disagrees with you, consider that you might be right and that you haven’t explained your reasoning well enough.

• If you think the sky is falling and the rest of the team disagrees with you, consider that they might be right.

• If design or code strikes you as odd, take the time to understand the reasons why the code is the way it is. If you then find the solution to be valid but confusing, you may only have to refactor to make it more meaningful. Don’t start rejecting and rewriting simply because you can’t understand it right away. That’s not courage; that’s impatience.

• If your courageous stand is met with resistance by decision makers who lack the necessary background to understand the situation, you need to present it to them in terms they will understand. “Cleaner code” is not likely to motivate businesspeople. Saving money, getting a good return on investment, avoiding lawsuits, and increasing the customer base are much better arguments.

• If you’re being pressured to compromise code quality, it might help to point out that you, as a developer, don’t have the authority to degrade corporate assets (the overall code base).