Executing Software Engineers for Bugs

> The resistance to change is stunning

If you ask a bunch of people who are analytically trained to ignore all the evidence in front of them you should expect this reaction. Especially if you tell them, to paraphrase, all they need to do is change their culture and all processes and everything will be rosy.

Pointing to books written by quality consultants isn't going to help your case much either I'm afraid.

Which is a shame. If you've ever been in an organisation that has this deep-seated view of quality it is quite an eye-opener. Of those that I am familiar with, only GE really were able to take it beyond manufacturing and definitely the only one where I saw it applied to software. It felt a little "religious cult"y at first but was pretty impressive nonetheless.

Your focus on Edwards Deming is a little unfortunate too, as I would expect that most people with an engineering bent will look at his work on SPC and, rightly, consider it inapplicable to software. It requires a high level of repetition to be valuable and software development doesn't have that.

His work on organisations could be applicable but it would require most companies to fundamentally change the way they approach almost everything. On the basis that it's not necessary to do this, I can only see it occurring if it became necessary. A special set of circumstances brought it to prevalence in manufacturing and by no means universally. If it happens to software I think it would need an equivalent set.

Yes. Good feedback, thanks. Deming himself said that any company can grow in a favorable market, so it is difficult to argue for better when indeed even running a company in a mediocre fashion can be highly successful as compared to the baseline.

What Deming's organizational view promises, instead, is joy in work. Very simply, that's what I'm really after.

You're so right!

It's the worse kind of dilemma: the kind that people outside the situation will claim was easy.

Personally, I think the Zero-effect case should not be cast aside lightly. Pragmatism is a legitimate ethical model.

I think you are putting the cart before the horse here, because current practice of software development is in a different universe than the one in which it is done as responsibly as you propose, and a developer's code of ethics is not the tool to move us there.

There have been projects of the sort you propose (the space shuttle software comes to mind), but they are few and far between, and it simply not possible to quickly change the industry in general without completely replacing it. Putting aside the technical challenges, it simply is not economically feasible - we don't have the resources.

The situation was very different with the Quebec bridge. At that time, the practice of quantitative engineering had advanced to the point where large, safe bridges could be reliably built, and all that was needed to make it happen was to deal with some human problems leading to sloppiness. The desired outcome was within grasp, and the public demanded it. Until the practice of software development reaches those points, a code of ethics is not going to make it happen. The department store collapse shows that engineering ethics need to be supported by society to be effective (and by support, I mean more than just lip service, and the support has to come from the people who set the agenda.)

Edit: Let me explain further what I meant by 'quantitative engineering'. Bridge designs are analytically verified to ensure that they meet a formal set of safety requirements before they are built. In contrast, almost all software is built and then tested (and fixed, and tested...) against an informal specification (even in iterative and agile methods, the building of parts precedes their testing, as it must.) Analysis is relatively much less important, and is generally informal.

Whoever claims that he never saw his software deployed to production with bugs has never written anything of any complexity. Adding "... he knew about" to that statement softens it a little, but not too much.

Problem comparing software engineers to the civil engineers lays in the ability of the latter to constrain their users, e. g. stating the weight limit for the bridge. Try to do that with software and enforce it.