My last post, Design Fail Patterns, dealt with the ways that people often select the wrong technologies for a project. That made me think of another way I’ve seen projects and people fail.

Cast your mind back to the days of the tall ships, great wooden vessels that plied the oceans under wind power. Imagine one of those majestic ships sailing along when suddenly it hits a reef, tearing a large hole below the waterline. All hands scramble to save the ship. They bail and bail, but the ship continues to sink. As the ship sinks lower, they bail more furiously until finally the ship is lost. The survivors are washed ashore on a nearby island.

As they stare out at the masts of the ship, still visible above the waves, the Captain asks, “Why weren’t we able to plug the leak?”

One of the crew pipes up, “Captain, sir, we were too busy bailing to plug the leak.”

OK, this is a contrived example, and it’s very hard to believe that it could occur in real life. However, very similar situations frequently arise in software development.

Bad Codebase

The most typical way I’ve seen this occur is on projects where the early work has set us up for failure. The infrastructural code is so full of bugs or badly designed that it has become a stumbling block to get the rest of the system built. The team furiously pounds away at the code, driving toward a critical milestone fixing bugs as they can. But with every iteration, things take longer to do and the codebase gets harder to work with.

In this case, the leak is the poor codebase. The only way to plug the leak is to rewrite that part of the system. Often, the programming team is unable to recognize that this code is a lost cause, particularly if they participated in its development. More commonly, the programmers know that this code is the problem, but they can’t talk management into the schedule slip that is necessary to fix it. In the end, the project takes longer to complete than if we had stopped and rewritten the offending code.

Unfortunately, a leak in software is rarely as visible or as easy to appreciate as a gaping hole in a hull. However, the programmers’ work to patch the system instead of fixing it is just as futile as the sailors who just keep bailing. And the result is nearly as predictable.

Poor Process

Another way this phenomenon is manifested is in adherence to bad processes. I worked on a project that used very poor configuration management techniques. The approach to version control was sloppy, and there were no controls for how integration servers were configured or how code was deployed for testing. Consequently, even though we would get successful tests on the integration server, we continually faced problems in production. These problems stemmed from several causes. Sometimes it was because of files that were edited on the integration server and not checked into source control, so they never got deployed to production. Or someone would set up the directory structure differently so that it would work on one machine but not the other.

When these problems appeared, the proffered solution was that people should be more careful. This case might be slightly different. Instead of thinking that you’re too busy bailing to plug the leak; in this case you believe that bailing may be all that’s needed.

I’m a firm believer that your test machines should mirror your production environment in every way possible and that you should deploy your code for testing exactly as it will be deployed to the production environment. And if I ever catch someone editing a file on a test or integration server, I’ll keel haul them!

No Time for Personal Development

I also see the “too busy bailing” mentality at work in peoples’ careers. As a hiring manager, I have interviewed hundreds of candidates for jobs over the years. I’m frequently amazed to learn how little people invest in their careers and the knowledge necessary to advance.

For example, most of my work has been on Object-Oriented projects. So, I typically ask OO questions of the candidates. One question is about how they learned OO programming. What books did they read? How did they hone this knowledge? Typically, I find that most candidates learned OO in college and have done nothing to build on that knowledge, other than their normal work experience.

I’ve also interviewed candidates for web development. So, I’ll get a resume from a bright young college student who is about to graduate. They tell me they want to be a web developer.

“Great!” I say. “So, have you ever built a website?”

“No.”

“Do you know HTML and JavaScript?”

“We had that in a class once.”

“Well, then what have you done to become a web developer?”

“I’m real busy with class right now.”

So, basically, this guy is looking for someone to pay him to become a web developer. I’ll always consider a new grad without formal experience, but I want someone who has done more than just sit through classes on their way to a degree. Show me some passion or interest in your area by working on something outside of class. Or at least have knowledge in the basic tools.

Tool Selection

The final way I see people being too busy bailing is through adherence to less effective tools. I often interact with people who have been using vi their whole career, or some other minimal editor, and just can’t be bothered to change. No amount of telling them how you can save them time will convince them to switch. They may even admit that they know they could be more productive if they switched, but they don’t want to take the time to learn a new tool.

Truthfully, this could be a case of the tool becoming the job rather than being too busy bailing. In that situation, a person spends so much time, say, hammering that they lose sight of why they are hammering: to build houses. So when a new way of driving nails comes along, they stick to their current way of working. “I’ve been hammering for 20 years. I’m not about to switch.”

Switching tools will always involve an investment in time. But if you pick the right tool, that investment will pay off rapidly.

So watch for signs of bailing in your own work and career. Consider whether there is a leak that needs to be plugged first. If not, then bail for all your worth. If you have spotted a leak and no one will listen, maybe you need to do a different kind of bailing.