There’s an interesting article on ZDNet here, quoting some supposed big-wig security guy – Howard Schmidt – asserting that programmers should be held personally responsible for bugs in the code they write.
It’s a very controversial topic, especially amongst the programmers themselves – let’s face it, we all know how much our code can suck, and we sure as hell don’t want to cop the consequences of it. Unfortunately, saving face or legal liability is not a valid excuse in and of itself. From a user’s point of view, it’s pretty simple – someone from company XYZ sold them ABC which is buggy. Company XYZ is responsible for that bug. Any sale carries with it some presumption of reasonable quality – if you buy a TV from a store and it can’t tune in to UHF properly, you’d bloody well take it back; you don’t just say “oh well, it happens”. You hold the store selling it to you responsible (and they in turn pass the buck to the manufacturer or distributor, etc). Software really has no right to be any different.
Once you’ve narrowed the blame down to the company, where it is likely wholly deserved, the breakdown is no longer clear nor singular. The company should have processes in place to prevent errors. They should promote good design & implementation practices, perform appropriate quality evaluation and control on outgoing software, etc. They are partially liable for any one mistake made by any of their employees.
But ultimately someone screwed up to cause the error to start with. Now, to be fair, like any screw up it can be unintentional and – in fairness – unavoidable. If the programmer is insufficiently trained, was under ridiculous constraints (“I don’t care when you think it’ll be finished, we need it tomorrow”), etc… then yeah, fair enough, I think people can forgive them a bit. But being forgiven is a far cry from not being responsible.
Personally I don’t concern myself with code quality as much as I’d like, but more than most people. I like elegant, simple designs with as few code and data paths as possible, because that eases testing and promotes stable code. And I do test my code reasonably well, but primarily only on expected behaviours and blatantly obvious failures. It is of course the subtle test scenarios which reveal those tricky errors. The problem is balance – I want to produce something in finite time, and quality is, after all, just another variable to be traded around. 90% may be good enough for a little hack if it saves half the time of achieving 95%. If I’m going to write some code for the space shuttle, I’m going to insist on at least five 9’s, and damn the expense. The right requirements for the job.
But this doesn’t absolve me from responsibility. I make the trade off consciously, knowing full well the risks involved in less than perfect code. And I take it on the chin when things do go sour. There’s no way out of it. My code, my decision – whether I want to admit it or not – to trade off quality for something else.
As a final end-note, I found it extremely interesting that the ZDNet poll on this topic shows that just 5% of respondents think programmers should be responsible – nearly 60% think it’s the company’s fault, and the remainder think “bugs just happen”. Sorry… “some men see things as they are, and ask why… I see things that never were, and ask why not?” Okay, so that’s a slight misuse of that quote, but it’s a bloody good one, and it does carry some weight in this situation. The world is not changed by acceptance, it is changed by defiance. We must always challenge ourselves to better ourselves, and never accept mediocrity.
