Outlining a World Where Software Makers Are Liable For Flaws

CowboyRobot writes with this piece at the ACM Queue, in which "Poul-Henning Kamp makes the argument for software liability laws. 'We have to do something that actually works, as opposed to accepting a security circus in the form of virus or malware scanners and other mathematically proven insufficient and inefficient efforts. We are approaching the point where people and organizations are falling back to pen and paper for keeping important secrets, because they no longer trust their computers to keep them safe.'"

Comments

Re:You can't trust code ...

[amicusNYCL]

That reminds me of an anecdote one of my CS professors mentioned. When fly-by-wire technology for passenger planes was starting to get rolled out, they polled some people about their willingness to fly on a plane that was controlled by a computer. The group that had one of the largest negative response was programmers. For everyone else the software is just magic.

Re:Sure

[ScrewMaster]

so a PE can get out of being liable for a badly designed bridge by putting the blueprints and the bill of materials on a sign before you get on the bridge?

there is a point where i agree that the programmers should be liable for their code - to the extent that it shows negligence. the fact that software for so long has gotten away with "good luck, thanks for the cash" mentality is kinda sad.

I am a programmer - and i would be willing to stand behind my code used in the environment for which it was intended.. but at the same time i would want to be compensated for the risk.. same way a PE gets compensated based on the scope of work they have to sign off on.

What truly irks me about discussions such as this is that everyone wants to lay the blame on the programmer. It is the organization that is at fault. Matter of fact, the responsibility for a defective software product lies squarely with upper management. Frankly, I just don't get this perceived need to roast programmers and software engineers alive, when defective designs in every other industry cause harm, and nobody talks about throwing those engineers under a bus.

Standing by your code is one thing: taking the legal responsibility for a finished, shipping application that has problems that you would certainly have fixed if you knew about them is something else again. Management decides who works on what project, how much (if any) quality control time is assigned to that project, management decides what bugs are minor enough to fix in an update (and sometimes they're wrong about that.) Management decides who to hire in the first place.

I work in an industry where my codebase, if it were to malfunction in any serious way, would be a major problem for some rather large plants worldwide. But here's the thing: if the responsibility (and legal penalties) for such problems were mine, and mine alone ... well, guess what. I wouldn't be a software engineer anymore. Why should I go to jail, or be bankrupted with legal fees, when I did a perfectly competent job, but a bug still managed to get by QC? Might as well put the QC team on the hot seat too: they're the ones that missed it. Fact is, the corporate veil is there for a reason.

In any organization it's the people at the top (the people who get the big salaries and golden parachutes) who ultimately maintain responsibility for such failures. And that is how it should be: they make the big decisions, they're the ones who allocate resources. Your average code monkey is no more at fault for a product failure than the janitor. That's why, unless there's gross mismanagement, it's the company that is penalized, not the individual employees. There are supposed to be checks and balances. Face it people: we know how to do code right, but most vendors simply don't want to spend the money.

That bridge you were talking about is a perfect example: the reason bridges don't fail very often because of design flaws is because those designs are reviewed and cross-checked and signed-off upon by slew of other engineers and designers who make sure the design is solid. It's that way because nobody is perfect. Again, who decides how much code review and design assurance is necessary? Yeah, you got it: management.

All the disclaimers in the world don't mean squat in court if your software causes significant economic or physical harm. The company that produced it (not the individual developers) certainly can be sued and redress granted. But penalizing individuals for systemic problems within a given organization? Even discussing that is patently ridiculous.

There's no good reason to burn engineers at the stake. Plenty of reason to boil a lot of CEOs and managers in oil though.