Why Aren’t We a Profession?

I saw an article in the New York Times that the lawyers who provided the legal rationale for waterboarding may be subject to professional discipline, but probably not criminal charges.

Without getting into any political issues, or whether these interrogation techniques constituted torture, or even if torture was justifiable, I’d like to talk about what this situation tells us about the legal profession.

In short, the operative principle is that lawyers are expected to adhere to a certain standard, regardless of any pressure from outside sources or circumstances, including what their bosses want them to do. From the article:

Among the questions it is expected to consider is whether the memos reflected the lawyers’ independent judgments of the limits of the federal anti-torture statute or were skewed deliberately to justify what the C.I.A. proposed. … Several legal scholars have remarked that in approving waterboarding the Justice Department lawyers did not cite cases in which the United States government had prosecuted American law enforcement officials and Japanese interrogators in World War II for using the procedure.

In other words, the Justice Department is trying to decide if these lawyers caved to pressure, or came to their decisions independently. The fact that they didn’t refer to cases that wouldn’t support their opinions indicates it was the former.

Think about what other professions are expected to adhere to certain standards that rise above concerns for any outside circumstances or pressure. Doctors are a great example. Accountants have international standards they must adhere to. Architects and engineers come to mind immediately. Do you want to live in a house that you suspect was approved by an architect because his boss was breathing down his neck?

My question is, why don’t developers have the same sort of standards?

Our world runs on software. If a doctor makes a mistake, maybe a patient dies. I suspect one day in the near future a software bug is going to kill an awful lot of people (ever heard of Therac-25?). Scenarios in which bad code costs a lot of people a lot of money are not exactly hard to conceive. And it’s only going to get worse as time goes by.

But even if we weren’t building systems that can seriously disrupt people’s lives, we still should hold ourselves to a higher standard. The code we write every day is essential to the businesses that pay us. If that inventory management application has an obscure bug in the spaghetti logic, one day it’s going to cause some serious issues for the company that trusts it – the company that trusted us to build that system.

Finally, developers are very well paid – about double the US median income – for our services. We should be counted on, as professionals, to do the best job possible. We should be trusted not to just slap something together to hit an arbitrary deadline to make us, our team, or our boss, look good. When we write code that’s fragile and hard to maintain, that costs our employer money – and not just a little bit.

The next time someone comes back to that code to fix a bug or add a feature, and they are afraid to change it due to a lack of automated tests, or they can’t quite figure out where to make the needed change, or they miss one of the seventeen places that logic is duplicated – that’s as much a loss to the company as if we just flat out stole the equivalent of the next programmer’s salary as he struggles with our sloppy code.

When we lie to our bosses about how close we are to finishing a project, so that management continues the project rather than redirect us to something with a higher ROI, we are responsible for wasting our employer’s money.

When we don’t bother validating a feature request, don’t get feedback on what’s really needed, and don’t exercise our own judgment, but instead just do the quickest implementation of the narrowest and most simplistic interpretation of the requirement/request, we have not earned our pay.

When we don’t thoroughly test the code we write (using automated or manual techniques), and just toss it over the wall for QA to deal with, we are responsible for wasting their time, as well as the ramifications if our buggy code makes it into the wild.

When, due to our own ignorance and laziness, we choose an approach, framework, design, or language that is not the most appropriate for the situation at hand, we are responsible for the results. If there’s a different approach that we didn’t evaluate but would have made the development faster, the code clearer and simpler, the maintenance easier, or the deployment and operation smoother, well, there’s nobody to blame but us, is there?

Software developers need to take responsibility for the decisions we make, or fail to make, and we need to do it collectively. We need to move toward becoming a profession.