Taking responsibility

Recently, the United States Navy ran into a small problem. Or, rather, a submarine of the United States Navy ran into a large one; specifically, the San Francisco, a Los Angeles-class attack submarine, ran into an undersea mountain at full speed (35 knots, roughly 40 miles an hour) that "wasn’t on the charts" the captain and his command crew used to plot their course. One man was killed, close to a hundred or so were injured, and the US Navy has since found that the captain and command crew were at fault.

Or at least, that’s the sound bite. The truth, as always, is a bit more complicated.

Essentially, the Navy found that the captain and crew plotted their course using a chart that didn’t have the mountain anywhere on it–it apparently formed long after the chart in question was drafted, due to some volcanic activity in the region. Had they used another chart, they might have seen that some kind of geographic feature (that is to say, either a hill or a mountain or whatever you call a big chunk of land at 400 feet depth) was reported in the area but not confirmed. Had there been any sign of some kind of indication of anything other than clear water, the captain readily pointed out that they would have chosen an entirely different path, thus avoiding the situation entirely.

But the Navy found the captain and the crew responsible, suspended them from active duty, and essentially held them accountable for the tragedy. The captain and crew aren’t fighting or appealing this decision–they accept it with full cognizance of the fact that this decision pretty much ends their career as Navy personnel. Oh, certainly, they can probably find some kind of desk job to slip into and quietly retire in some number of years, but their upward advancement within the Navy is over. They’re quietly accepting the findings of the Navy–that they were at fault, for a good reason: they were at fault.

Before you start thinking I’m being harsh on the captain and his crew–after all, it’s not necessarily fair to hold them responsible for the contents of the charts–bear in mind that the Navy makes the captain’s role explicitly clear: in the final accounting, the captain is the final party responsible for the safety of his ship and his crew. In essence, with the captain, to quote the colloquial, "The buck stops here". Thus, by definition, anything that happens to the ship or its crew falls under the captain’s responsibility. Far from jumping on some bandwagon of "blame the captain" for the tragedy, I have the utmost respect for the man, despite never having met him, because he’s stepping up to the plate.

Recently, at the Reston, VA run of the No Fluff Just Stuff symposium, I was hosting an architecture forum, and was asked, "Why do you think projects fail?" Members of the audience chimed in with their favorites, including "Management!", "Bad requirements!", "Users don’t know how to identify what they want!", and so on. What struck me about these answers was that no one, not a single person in the group, even hinted that programmers might be to blame.

This, to me, is a disturbing trend.

I’m not about to suggest that the only reason that software projects fail is because of the programmers working on it, just as the San Francisco’s tragedy was hardly due to incompetence on the part of the captain or crew, far from it. The captain and his crew demonstrate their competence clearly, in the basic fact that all but one of the crew survived what clearly could have been far far worse. Programmers frequently demonstrate their competence by exerting vast amounts of blood, sweat and tears to ship projects that, by all rights, shouldn’t come anywhere close to a production server.

But we must never lose sight of the fact that, at the end of the day, a software project’s responsibility rests with us, the ones who have promised our bosses/clients/customers that we will deliver something useful. Just as you wouldn’t find it acceptable that your package sent through FedEx doesn’t arrive "because the van broke down, hardly our fault, right?", it’s not acceptable that a project fails because "the servers got hacked" or "the requirements weren’t clear" or "the programmers found it took longer than they thought" or….

At the end of the day, the buck stops with us. Regardless of the reason, regardless of whether it’s something we can control, it’s our job to ship software, and if a project doesn’t ship, we should accept that we failed somewhere. Doing so gives us the moral authority to then cross-examine the failure itself and drill deeper within the failure to find root causes that might have contributed to the failure, and fix those root causes. It’s not an easy admission, but in the end it’s the admission we have to make.