Slashdot Mirror
Holding Developers Liable For Bugs
sebFlyte writes "According to a ZDNet report, Howard Schmidt, ex-White House cybersecurity advisor, thinks that developers should be held personally liable for security flaws in code they write. He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system. He was speaking in his capacity as CEO of a security consulting firm at Secure London 2005."
I will admit that I have seen a lot of bad programmers and bad code over the past few years, but let's step back and think about this. Programming jobs are rapidly being sent overseas to India and China. This is not going to create much of an incentive to keep such jobs in the States, nor does it create much of an incentive for people to go into the field. Holding companies accountable, as suggested in the article, might be a slightly better solution, but again it's somewhat complicated when you start trying to hold an overseas company accountable. (It's more doable than holding an overseas individual accountable, but still not a simple task).
As for the article's last point about CMM environments: It's not at all an indication that software has been developed by quality developers, all it means is that the code was developed using a reasonable development framework. CMM level 3 means that you document your processes, and typically have peer review. Bad peers means peer review is worthless - it does not guarantee good programs. CMM Level 4 involves"quantitative quality goals" by which productivity, quality and performance are to be measured. This is a bit better, but again it's a matter of where the bar is set. CMM Level 5 is about continual improvement, and is extremely strict. I think that CMM Level 5 is the only environment where one can actually be assured of reasonable quality code. I've seen way too much bad code come out of CMM-3 and -4 environments to give them much credit. If you've got great people, then a CMM-3 environment typically produces great results. For -3 and -4, what you put in is what you get out - not guaranteed greatness.
About this little thing called "the mosquito" which we received as part of Earth v1.0....
Whatever happened to holding the people who exploit vulnerabilities responsible?
steampunk web design
You need proper code reviews, etc. if you want to find security flaws. The company writting the code should be responsible for organizing such things.
Facts do not cease to exist because they are ignored.
Remind me not to work for this guy.....
Why not make CEO's personally liable for not putting the code through proper QC channels and selling it over-promised.
Made to sell, not to use? Who's fault is that?
B-)
A friend will come and bail you out of jail, a true friend will be sitting next to you saying, "damn that was fun!"
That proposal sounds fine, but then we should hold government leaders personally responsible for wrongdoings of government.
I'd love to see the some jail time or a fine for Mike Brown after Katrina, or how about some jail time for Bush after the false pretences of Iraq?
Want me to pay 10x more attention when I code?
Pay me 10x more. And don't be in such a hurry for your product to get completed.
No, gun manufacturers should be liable for producing faulty safetys which do not function properly, or firing pins which may actuate without a trigger press.
Is it just my observation, or are there way too many stupid people in the world?
It's usually poor management that forces the product to be out the door 6 months before it's ready. Either keep your job and release a buggy product or stick to your guns and get fired. I think it should be the company, not the individual developer held accountable. How the company handles things internally is up to them.
---
Programming is like sex... Make one mistake and support it the rest of your life.
Sure, let's sue the pants off anyone who does anything wrong. Let's make it impossible for anyone to create anything new or different. Cradle-to-grave protection, ensured by armies of well-intentioned and socially-responsible attorneys -- that's the sure way to economic success!
Not at all. It'd be like holding car manufacturers liable for defects that cause people to get hurt.
And we do that today.
Why should software be any different, except that writing bug-free software is probably just as hard as designing a "perfect" car.
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Only if the gun blew up and killed the shooter.
Your comarison doesn't match because developers would be held liable for a skill that they present as "Professional". Similar would be making the brick layer accountable for a building coming down.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
While I agree that accountability is a good thing, liability without major restrictions seems like a dangerous thing. I am a software developer myself and I give my clients the guarantee that all bugs they discover within 6 months will be removed free of charge. Since I have no knowledge of how much losses they will claim as a result from even trivial bugs (yes, some clients are greedy), accepting liability is not something I'm going to do.
see a Text Widget
You can as well ban "software development" as a trade. After all - WTF? You get what you pay for. I say that your average "in-house" enterprise software system has complexity no less than Toyota Camry or something. The difference being that software would be developed by 1-10 men during a year or two whereas any other _industrial_ design costs (both in $$$ and "man/hours") much, much, much bigger. But who cares? Get back to coding, you idiots!
CMMI doesn't guarantee good practice any more than membership in the Better Business Bureau guarantees good business. But I'd rather work in a shop that has CMMI in place than one that doesn't. It's insurance against the sort of death marches that create slapdash practice, shoddy product, and security holes in the first place.
I am currently the Development Lead / System Architect at my company. In my experience, the majority of "issues" and or "bugs" that I have seen crop up have been directly tied to poor requirements gathering by our "Business Analysts".
Often, it turns into a real pissing contest between the two groups. Usually, after testing reveals that the grand vision of the BA is a crock we will usually revert back to the original recommendation of the development group.
Yeah, let's blame the developers for the problems. That's the ticket.
When you die, on your deathbed, you will receive total consciousness. So I got that goin' for me, which is nice.
I didn't catch the ex- part the first look and thought "whaaaat?" as I know the current White House occupation force is very Microsoft Friendly and would never endorse such sentiments.
A feeling of having made the same mistake before: Deja Foobar
It's not always a question of the coder, and a bug is not always a bug. In the example in the article, for all we know the specification called for a plain-text transfer, and the coder did exactly right.
So we'll have yet more wrangling over specifications, more walls between users and developers, and more CYA behavior. That'll be fun.
-Jeff
Please learn the difference between a dissenting opinion and a troll before you moderate.
He doesn't seem to think that writing poor code is entirely the fault of coders though: he blames the education system.
You know, I don't think it's entirely his fault that he's an idiot: I blame the education system.
Look at it this way. There are already laws on the books that say I can sue company X for giving me a POS. Why go after the poor slob who works for the company. If I have a blowout on a tire on my car should I track down the guy on the assembly line that was working that day or go after they company whose prosess stinks?
TT
So should we hold construction workers who help build a house that gets burglarized be held personally responsible?
No kidding! If a car manufacturer produces a car that has a faulty part, is the engineer held laible? Hell no! its the company. You don't hear John Doe recalling the cars. Its GM that recalls it. Whether John is fired or not is a different issue and up to the company. Similarly the Software company is liable for the product. You blame Microsoft (sorry it was an easy target)!
While individuals can make stupid mistakes, the real problem is in the system and managers are ultimately responsible.
As a simple example, take a web application. The web people believe (reasonably or not) that the form fields will be cleaned up by the backend people. How do they know what's dangerous anyway? The backend people believe (reasonably or not) that the data will be cleaned up by the web people. How do they know the various encoding schemes used, etc.
Then some **** adds a cross-scripting exploit and compromises sensitive information.
Who's responsible, the developers or the managers? Even if the developers are paranoid, what about the errors introduced as everyone tries to handle conditions outside of their sphere of knowledge? What about the new security flaws introduced by that?
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
This is just what the software industry needs: Another business guy who has never written a line of code trying to tell the rest of us how to do our jobs. For all of the whining and crying about bad software you'd think they'd actually put the developers in charge for once. I can't speak for the industry as a whole but from my perspective 70% of the problems in the development world come from business types setting impossible deadlines and failing to listen to their developers.
How would this affect OSS projects? Would the development community be liable for damages caused by bugs in software? I have seen alot of free software that comes with a disclaimer waving all responsibility of the author, would that still hold up?
We hold them liable for defects that cause people to get hurt.
If you're going to attempt to compare apples and oranges, let's at least use an orange colored apple, shall we?
It'd be like holding car manufacturers liable for not making a car absolutely impossible to break into.
Hold the vendors responsible. They are responsible for 100% of all problems that are not the fault of the customer.
The vendor then holds the devloper responsible. They are responsible for 100% of all vendor bugs that are not the responsibility of the vendor.
The developer then holds the programmer responsible. He or she is responsible for 100% of all developer bugs that are not the responsibility of the developer.
It's the way it works everywhere else. If you have a faulty product, you take it back to the shop. They then take it back to the manufacturer and if it's a fault caused by a specific individual, they either sack him or train him properly. The purchaser would generally not sue the guy on the production line or the designer, even if it was their fault.
There are good reasons for doing things this way. It preents people from passing the buck. It means each entity along the line is wholly responsible for ensuring quality.
Nonsense.
Cheers,
Ian
Few people on this planet can afford software developed to such a standard.
There will always be a market for "cheaper" software that is not guaranteed to such a level, and with support contacts instead, where developers will try a moderate ammount to fix problems as they arise.
From another perspective, the market is demanding of cheap software - not good software, which is why there is so much of it.
Sam
blog.sam.liddicott.com
To put the entire blame on the developer misses the point.
While programmer ignorance, incompetence and/or laziness certainly plays a role in the problem, there are other factors that should be considered:
(1) Death-march-style deadlines imposed by management, leaving no time for proper design, threat modeling, or testing.
(2) Security flaws in the underlying infrastructure (operating system, network, etc).
(3) Malice/stupidity of authorized users to bypass established safeguards.
Security is the responsibility of everyone involved in the creation, management, and use of a system, not just the hapless developer.
2. What about laissez-fair management that ignores any such processes that are in place so to ship code on some arbitrary market-driven deadline?
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
This is absolute bunk! Most often, programmers would have a 5-10% stake in responsibility when compared with the mountainous bureaucracy above them. Consider how often a non-technical exec overseeing a software development project will agree to a contract that is nigh impossible to complete on-time. The customer holding that contract begins squeezing testicles, placing pressure (by extension, through the bureaucracy) on the entire development process. The exec says, "You mean there isn't a programmer writing or debugging code this very instant!? What a crime! You're not doing your jobs properly!" The truth of the matter is that ~30% of the project timeline should be research and design. Without a good design, and resources on-hand, bugs creep in. It is impossible to test quality into software, it must be designed in.
Programmers don't draft contracts, they don't set deadlines, they don't make budget decisions, and certainly aren't responsible for failing to keep bugs out of a system that was (due to poor decision making in the aforementioned areas) designed to have bugs.
I pity the foo that isn't metasyntactic
I think I agree with the British Computing society moreso than with Mr. Schmidt. I think coders should be held responsible, within a company, for poor code that they write, but overall the company should be held liable for bad code that it ships. If a company fails to have proper QC, then it's the company's fault, not the fault of a lone coder who might have written an insecure subroutine. Most companies don't have single coders, and rarely is there a single coder who has full (100%) knowledge of the other 10,000,000 lines of code in the product. I think proper education, as stated in TFA, is a better idea. Why not send the employee to a security class if the coder continually writes insecure code? That'd solve the responsibility issue and the education issue. Then, the company would produce more solid code and everyone wins; especially the consumer.
Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened.
I write financial reporting software for my company. Before anything is installed, even the most minor one-line bug fix, I have to sign a Sarbanes-Oxley statement of compliance. There are criminal consequences for not performing these steps properly. My QA person also has to sign this. My CIO is also held personally responsible, in that he/she could go to jail if something I wrote caused inaccurate financial reports to be released.
I suspect many people who write software, like myself, are already personally responsible. And so we should.
Processes can aid in ensuring consistency, but they aren't strictly necessary.
I worked as a development/support programmer in a fairly critical application area for a major airline for over ten years, and we had a small tight team of a dozen fairly experienced developers and only a few formal processes in place. The software that was written and loaded in production was generally of very high quality, mainly due to a good culture of informal peer review, testing (involving users and programmers alike), heavy use of a test system to let changes simmer a bit before release, etc., but there really wasn't a formal "metholodogy" in place, just common sense practices that everyone there had agreed to follow.
For larger groups or in development environmments where software is released in bursts (e.g., a new version is released to external customers every few months) it might make more sense to put more formal processes in place, but when working on a living system that has to change from time to time in a few days (or even hours) I'd rather put my faith in a couple of experienced programmers who know the system and the expectations of the end users.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
1. You cannot become a doctor without long theoretical and practical training, intermixed with hard exams. All this is heavily regulated. To become a coder, you just have to pass a job interview. Software engineering certifications are optional and generally regarded worthless.
2. Doctors are insured against malpractice. The costs are high, and generally passed on to patients.
3. Doctors can choose not to operate (administer drugs, etc.), if the action constitutes malpractice. In software industry it's "use this braindead tool, or get fired".
4. Malpractice. Ok, today's revolutionary therapy, maybe tomorrow's malpractice (or vice versa), and experts might disagree about some practices, but there is some sort of general agreement on what constitutes malpractice. I'm not sure whether IT is mature enough to speak of "malpractice" here.
To sum it up: yeah, you can make developers liable for their mistakes, but the consequences would be huge. The costs of IT would skyrocket. Are you ready to pay for that?
Dammit!
I'm so fscking SICK of these people who treat as if it's something that can be permanently gained by doing A, B, and C.
BULL!
Security is about understanding your platform.
It's about knowing the strengths and weaknesses of said platform.
It's about maximizing the strengths and limiting/minimizing the impact and exploitability of the weaknesses.
It's about doing A, B and C, to get going. Then next week, you do D and E. Then think about implementing F. But make sure that it doesn't conflict with B.
Also, they need to understand that security is NOT about keeping people out of the system. Face it. If someone wants to get into your systems bad enough, they WILL get in. Regardless of your protections.
It's about making it so difficult to access it in an unauthorized manner that:
A: The invader gives up and moves on to easier targets.
B: Spends so much time trying to gain access that he gets noticed eventually.
C: Has to utilize truly heroic (and traceable and wildly obvious) means to gain access that he gets noticed right away.
So please, people! STOP with the damn pipe-dreams about "totally secure" systems already!
The only "totally" secure system is one that's been rendered down to shavings and disbursed in random geographic locations via wind, water, and other means of distribution.
Chas - The one, the only.
THANK GOD!!!
1. We can pass the blame to any bugs in libraries or other peoples code that we use to them or if there is a bug in the operating system, because we followed the specs of the 3rd party tool but the 3rd party tool is not working up to specs.
2. We get paid for the full development cycle, and no pressure to get it done on time, or even close.
3. If the Specs for the application never changes from the writen specs of the application before it is written.
4. We are not responcible for any flaws that happen in old versions when there is a newer version out there.
5. The Latest version of the Application is younger then 3 months.
6. The application went threw full debugging and testing for 2 years with at least 10 people per line of code.
7. The application doesn't try to keep compatibility with an older system.
8. Is used on hardware the specs were approved in and were created before the release of the application.
9. And if the developer wants to support it.
When developing a Car or builing a house, there is a lot more prework that goes in they know what they want and how it works before they build it. Programming right now is not setup like that because it is to expensive for a single application or a custom application. Plus it will make more people decide not to be a programmer if they are responcible for every code they ever wrote.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
My first reaction was: I wonder which lobbyist of a Large Software Company helped put this one through?
The programmer is personally liable, but the big corporation who employs him/her profits from the work? Wasn't the whole point of creating a corporation to put a degree of separation into liability?
Also, even if A Large Software Company promised to protect their own employees (some liability insurance as part of the benefit, say), this would still be bad news because it discourages independent programmers and coerces everyone into joining A Big Corp.
A better idea would be to make it optional, like certification by a licensed Software Engineer. Just like, for example, how you could build your own toolshed with wood and hammer, but to build a house, you have to get a Licensed Inspector or be a Licensed Civil Engineer or something. (Details fuzzy, but you get the idea.)
Okay, now to go RTFA.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Exactly. If a software makes $1 million. Do the developer(s) get the million? Then why should they be held responsible for the "loss" and not profit?
"There is no flag large enough to cover the shame of killing innocent people."--Howard Zinn
Rather than deal with the problems that lead to insecure code (usually management based) most companies will take out insurance. And this has worked so well for Medicine...
Producing good code is a complicated process, not something one person can do.
:-)
There are dozens (if not hundreds) of examples out there of high-quality code being produced by a single standalone programmer, some of them fairly complex applications/utilities, and that is true not only in the DOS/Windows shareware and open source software environments but also in the corporate mainframe environments where I've worked.
Yes, such folks will generally have other folks to testing over time, but often the concept, design, coding, and initial testing stages are all handled by a single person who has the technical skill, vision, and determination to create the initial solution and whip it into workable shape. Once that basic foundation is in place, feedback from others is solicited.
A person who doesn't care about quality or who isn't technically adept enough to avoid problems is probably going to produce a bad piece of software in the end regardless of the processes in place unless everyone else in the development chain holds his/her hand.
A person who is obsessed with clean code and who has a clear vision, on the other hand, can often perform amazing feats with little more than a single PC or terminal, a pizza delivery service, and a few hundred gallons of coffee (or Mountain Dew) at his or her disposal.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Software is a bit different than anything else you can compare it to. It is essentially "living" math equations. To prove a program to be perfectly functioning is the equivalent of proving a huge mathematical statement... except because of that good ol' Turing completeness you can't ever prove that an arbitrary program will halt given any type of input (that's not to say that you can't severly limit the cases, and it is possible to design a program that you can prove will halt, just very hard for any complex piece). I could go into this further but suffice it to say that proving quicksort sorts on average of nlg(n) is one thing, proving that your program will perform every function as desired is quite another and would take decades to produce any piece of software of any notable complexity. Adding to this... your software is running in an environment on an OS that it doesn't control which can have any of a variety of patch sets and have any versions of various drivers while also running along side other software that may affect your program by hooking into it, corrupting files, eating all the memory on the machine, thus screwing your program and causing it to possibly crash in the middle of an important cycle. Its not like the Universe where you can be pretty sure what physical laws you're dealing with. In software there are no set of standard "laws", every computer is a different "universe" with different hardware, different programs, different speeds, different amounts of memory, things like antivirus and anti-spyware wil interfere with how your program functions, viruses, and random operating system quirks. Your software relies on the operating system to be perfect, and to prove the operating system to be perfect I would imagine would take on the order of 5 decades, while at the same time forcing the software to not be advanced or changed at all because the proof would have to start from the beginning again. Then for every bug found while proving the operating system functions as desired, when that bug is fixed the proof would have to be done all over again from scratch. The world of software is different then any other industry in the history of man, and as such can not be compared with industries that make physical products. If you don't want technology advancement to crawl to a stop, then don't support this.
Regards,
Steve
Is the sign of a profession as opposed to a trade or a craft. If we want software 'engineering' to become a true discipline we need to hold software 'engineers' accountable. In every other engineering profession insurance for errors and ommisions is required to practice, basically malpractice insurance. Even contractors, plumbers and electricians often must be licensed and/or post bond. Why not programmers?
Any company reselling software in the US developed overseas would carry the liability and there by apply the same rules to overseas programmers (e.g. an offshored CPA must still pass a CPA exam or selling that person's services as a CPA is fraud).
In addition, development of and adhesion to best practices would have to then be done by companies or they would never get SE's to work for them. The liability issues would be too great, and this would force companies to actually develop best practices and processes.
It would make sense to do this.
putting the 'B' in LGBTQ+
when you buy a car, drive it, the breaks fail, you hit a wall and die... who is held responsible? the company that built it.
when your airplane crashes in the middle of the ocean due to engine failure... who is held resposible? the company that build it or the airline.
the answer is never the designer, engineer or whatever.
Superb Hosting
So, not content with the actual state of things (an ever decreasing number of young people willing to chose a career in the software development field, at least in most developed western countries), the guy wants developers to be held responsible for the bugs they introduce (and as if that was that easy to determine): so basically no one will want to be in the field anymore, which will just make all things worse and force us to outsource every development work even more than we already do. Yes, all in all, a great move indeed.
Programmers are not a parallel to automotive makers; they are a parallel to Authors, Book writers. Can you think of anything more absurd then suing an Author of a book over typos? Or the reviewer of that book who says "this is the best book of the year" and you thought it was the third best?
This is the same reason patents on software are ridiculous, can you patent a love story plot? It's just absurd. This is another example of our society's run-away liberal government mentality. Big government stifles creativity, freedom, and crushes capitalism.
A case like this should be thrown out of court as a frivolous lawsuit and the lawyer held in contempt, but we won't get that from activist judges.
Under oath, Clinton was given a very specific definition of sexual relations, and according to that definition he didn't have sexual relations with Monica Lewinsky. Where he did lie was to turn around and say the same thing to the American people. We didn't give him any such specific definition, so he should speak our language.
I would agree that this could possibly be good for developers. I've done things quick-and-dirty, against my better judgement, and with flaws that I personally would have preferred to remove many a time because management wants it done fast and just barely meeting the contract specs, and bugs can always be fixed "in the support phase."
That said, programmers would start having to behave like Engineers, and I'm not sure they're all ready for it. It would be a rocky transition for the industry. I don't think management will be happy to hear the sort of estimates that come from engineers whose personal reputation is on the line in a design-- before I'd sign off on anything personally, I'd be damn sure it was right and that there was a rigorous test plan to make sure the implementation worked as planned when we were done. Costs for software will go up dramatically, but so will quality. Still, I suspect it will be a tough sell to management, who will fight any sort of liability legislation tooth-and-nail.
Who gets sued has to do with who has the deepest pockets. If there is a billion dollar software company and a 50k programmer who introduced a defect. The lawyer for the plaintiff will counsel that the company and the store that sold you software (assuming it is a big store chain) will get sued to maximize the lawyers return on investment (not necesarrily yours). You see that with car accidents as well where the car company might also be getting sued if it looks like an argument can be made. Not that it make any sense but it will mean usually it is better for a company to settle than to pay their own lawyers big fees to take something to court where they might loose.
Doctors are leaving my State because of this practice. Malpractice Insurance is way up. Not because there is more malpractice but because the laws of the State and the courts and the lawyers are having a field day, and orgy of wealth sharing. (Well sharing among lawyers).
Its more a lawyer wealth acquisition opportunity than a user or industry complaint resolution or redress technique.
How many times have you heard a plaintiff say "I'm not suing for the money, just to get satifaction or prevent this from happening to someone else". You don't hear their lawyer saying that (pro-bono aside) so often the lawyer gets much much more of a settlement than the plaintiff. Wheres that at. Usually it is structured that the lawyer gets 50 or 70% of a settlement, but wait I'm not done, lawyers expenses (including time spent) are taken off the top before the split or taken out of your split. And I though project managment was a racket.
You're right, but you don't go far enough.
The fact is that the supply of competent people in the world is vanishingly small, whether they be programmers, managers, or people whose job it is to procure things. I'm not talking paper qualifications, I'm talking about functional competence: the ability to handle a complex and uncertain situation, and make the right decisions. It's generally found among people like farmers and blacksmiths who know their business because it is part of body of knowledge that has been handed down from time immemorial. Marketers, managers, software engineers and other people engaged in modern professions -- well lets say good ones are rare indeed.
Furthermore true integrity, the type that makes you do the right thing when it's easy to pretend things are better than they are and leave some other poor bastard holding that bag -- that's even rarer.
Software, like most other modern products that are intangible or have a significant intangible value components, is a product of the Shambling Juggernaut of Incomptenence and Denial. The SJID, it must be admitted, works far better than it has any business to. People caught up in it interact like atoms of gas, the composite average of which produces a tolerably reliable mediocrity. Occasionally it will miraculously spit out something wonderful, and not unusually it will produce something horrible, but the machine roles on. And what keeps it running is Denial. Incompetence is the common denominator to be sure, but denial is the fuel that drives the machine and the glue that binds it together. Success has a thousand fathers but failure is an orphan. Those who have reason to be glad of this find their most natural home in the SJID.
Unfortunately for you, dear Slashdot reader, there may be no place for you here, because unlike the marketers, management consultants, CEO, board, procrement agent, and virtually every other party in the software development arena, you left a paper trail of every mistake you made, no matter how small or how minimally contributory to the overall failrue it may be. Blame is supposed to ooze throughout the system so that pain and damage is not felt in any one place, but instead diffuses into a general atomosphere of dissatisfaction and helplessness. But you, dear reader, carry the antibody of Accountability, which can reliably attach to Blame in concentrations as low as 1 PPM.
And now, they've noticed. Beware.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Yeah that's the point. Don't take money to do bad things.
If your employer says "get this ready tommorow or you're fired" you're probably not at a good place anyways. And if enough people held such personal convictions the employer would have no choice.
That said, all too many developers don't do their share of documentation or proper development practices. how many developers write doxygen/javadoc comments? How many developers verify their code? Write use cases at least? etc...
There should be liabilities for software developers. Otherwise what are they worth if any "monkey" can develop software?
Tom
Someday, I'll have a real sig.
Damn. I guess this means the end of Microsoft, and Linux, and FreeBSD, and UNIX (I would say SCO-UNIX, but let's face it, they're gone already), etc. - God knows they've got plenty of names lurking in their code and all have had some sort of vulnerability at some point in time. I guess all that'll be left is OpenBSD, although that one exploit may come back to haunt 'em.
On another note, I'm curious to see how Mr. Schmidt would lke the liabilities to be addressed. Are we talking say a $5.00 fine for typos, $100.00 for DLL/Library breakage, $1000.00 for a viral vulnerability, and, oh, maybe $1,000,000.00 for a exploit that grants root privileges? Would these penalties be scaled by installed user base so that smaller companies like Bob's Fuzzy Linux won't go bankrupt after the first lawsuit? Or will larger companies be able to buy "vulnerability credits"?
I'm not tense. I'm just terribly, terribly, alert.
I think you missed an important engineering concept known as the "tradeoff". Usually 100% verification of software is just not possible [e.g. prove me your implementation of AES works for EVERY plaintext/key combination]. And bugs are normally not intentional but simply in use cases developers/coders haven't explored.
So while I agree with the sentiment that bug free software is possible this notion that no software [or hardware for that matter] should never have a bug is ludicrous and isn't even reflected by the "real engineers" [e.g. people who build buildings, roads, bridges].
Tom
Someday, I'll have a real sig.
The best medical care system in the world comes from keeping the insurance companies out of it. Instead of paying a team of 12 to determine if you should be healed, then paying a doctor to heal you, we just get the doctor to heal you and call it a day. It's much more efficient, and enriches everyone except insurance salesmen.
Insurance was created as a concept to deal with the fact that in a purely capitalist society there is no sense of community or common good and no one will help you when you need it most. Does anyone actually consider it to be an efficient and effective means of addressing this need?
-1 Uncomfortable Truth
Wouldn't this utterly destroy the Free Software movement? (Incidentally, we'd probably lose the internet too).
Reality is defined by the maddest person in the room
And who is going to pay for this?
We create a "secure" web browser but, its gonna cost $10K per copy. This will cover the cost of developemnet, security auditing, extra QA, and the dev cycles that go along with it. Since, the OS can't be trusted to run the browser, it will only work on a dedicated browsing computer with no operating system. Since other peoples code poses a risk, it will not run javascript, java, flash, or any kind of plugin.
Who would buy this?
If developers are carrying malpractice insurance, then the insurance companies are going to have a lot to say about how development is done, and *if* it should be done. Your boss hands you a project specification, you send a copy to your insurance co. You then tell your boss that you can't work on his project because you won't be covered.
Developers are going to have to charge a lot more for their services. Both for the personal risk involved and to cover the cost of insurance.
Programs can be made "more" secure and have "fewer" bugs but, its going to take more time. Time=money. Look how eveybody is whining that Microsoft is taking too long for the next version of windows. Maybe if they want it to be *secure and bug free* they'll tell MS not to rush; to take a few extra years to be sure about the product; and they'll pay more for it.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
If I have to carry professional liability insurance, I will have to charge some very prodigious rates. These will be rates on a par with what doctors charge. Which means that I'm driving a new Mercedes in the not too distant future.
At least in theory, companies will simply refuse to hire domestic programmers because their rates would be too high. However it's likely that companies could become pretty risk-averse and unwilling to hire foreign programmers, since they will have no recourse when the corporate data is compromised. The discrimination against foreign programmers will become similar to what is faced by foreign doctors currently.
Likewise, because of the increased expense, companies will buy far less software in general, and they will plan our their real needs a lot more carefully.
I can't say if this will be good or bad for programmers in the long run. Attorneys and doctors seem to be prospering and they live under the same burden. It could well be that placing professional liability on programmers and weeding out the pretenders would be good for those that remained. The only question would be which of us would remain?
Easy Online Role Playing Campaign Management
So, heck yeah, cripple the IT economy, and make me stinking rich!
Life, the Universe, and Everything... in my image.
For example. Today, I set up HPLIP for the first time instead of HPOJ for my PSC2110. What a pain. I had no problems configuring or making, but then there was an issue when I tried installing. Clearly the HPLIP programmers' fault, right? Or was it that I was using a Slackware derivative with a mixture of packages and as a result, many libraries and config files were in non-standard places? I would have guessed that if ./configure && make worked, everything was found properly. But it wasn't. If my nonstandard config was the problem, then perhaps I'm responsible. Eventually I got everything working but with one caviat. I could only scan as root.
In the real world, if this happens to a litigious happy individual who likes to bill $400/hour, he'll sue:
While this may actually be feasible for shrink wrapped software that sells a million copies and has a team of expensive testers going over it button by button, this would completely destroy custom programming.
I write software that is usually only run on one or two computers at one location, and it's constantly modified to add features, fix bugs, etc. Our company and our customers can't afford to pay triple the cost for the stringent software testing that a huge Micro$oft type place would have, so a law making the programmers personally liable would make all custom software prohibitively expensive.
We do sell our code with a 1 year warrantee, so we agree to fix all bugs that come up within the first year. However, the agreement is not a guarantee. If there is a bug, we agree to fix it, but we're not going to compensate the customer for lost production or expenses.
There is software in this world (I'm thinking the QNX kernel here) that actually comes with a guarantee that it works as documented. The company (QSSL) has liability insurance just in case. Of course, that makes QNX licenses more expensive than they would otherwise be.
Most software comes with a disclaimer. Microsoft tells you that the user accepts the liability for any bugs. Even though nobody reads that disclaimer, it still exists. Right now you have a choice - you could hire someone to write code and give you a guarantee (expensive), or you could just buy something off the shelf (cheap) that would probably work ok most of the time. The article is talking about removing that choice.
"I have never let my schooling interfere with my education." - Mark Twain
People/companies are not writing bad code because they are sloppy or doesn't want their code to be secure or correct. They write bad code because there really is no way ensuring the security today. If there were, price insensitive things like battle ships would not be dead in the water because of software error. I suppose you could make code reasonably secure for certain certified environments e.g. Running a certain build of MS-Office on a certain build of Windows XP in a certain hardware in a specified configuration.
What if the user doesn't run it under the conditions specified e.g. connect it to the internet and internet was not covered by the specification should the developer be liable then? Of course you could hold the developer liable no matter what. But that would put software development in a different position than all other products. E.g should a building contractor of a high building be held responsible for the damage to a parked car outside the building caused by somebody jumping from the roof in the act of committing suicide? I think not, even though the errors in building construction making this possible and the means to fix them is much more evident than most software problems.
The only thing that will happen if this was introduced is that software prices would go up radically as software companies or individual developers need to make sure the make a profit even if they have to pay damages now and then. I.e. the price of the software will have to pay more lawyer and insurance fees. If this is introduced in a country the cost of running a business will increase significantly, and I am not just talking about software business. How many businesses would afford to have the cost of their IT infrastructure increased by several orders of magnitude. A country that introduced such laws would kill all business that need some kind of IT support, at least if it did not also have very high customs fees or taxes for imported products and services.
As for the software industry of such a country you would probably see fewer and bigger companies with the money to bury customers claiming their rights in legal process for a very long time perhaps until they go out of business before they get their money. The fact that there was fewer actors in the market would in itself raise the price of software due to less competition. It would also slow down the speed of development. If you for instance create a new version of an office productivity suit, you would probably want to test it for several years on a group of subjects that have waived all their legal rights before you release it to the general public. Then you would like to profit from that investment for a very long time. Perhaps 20 years or so.
God is REAL! Unless explicitly declared INTEGER
There is over $3B spent a YEAR on "cybersecurity." So far, they've implemented an email alert system that tells people of new viruses/worms going around. They've convicted less than 10 people. They made claims that Al Queda operatives can turn off the Internet and disrupt powerlines through a modem in a cave (even though powerlines are turned off through a physical switch).
:)
.NET/Java/Python etc etc)
Now, our Cybersecuity making an outrageous claim that developers held responsible for unforseen security breaches. I would only be up for this if every time someone does a buffer under/overrun as a security breech that the OS developer be held responsible - Microsoft
There's many layers below the developer that can have security holes:
* the virtual machine (for
* The OS
* the hardware's firmware
* an error in the processor
* the API the developer uses
* poor requirements
* encryption algorithm flaws
* idiot bosses who proclaim that a product MUST ship on time
This guy is nothing but a tool of the government. All of cyber security has always been this way. My only regret is not joining them to get a piece of the terrorist/cybersecurity pie they're handing out due to FUD.
In the Code of Hammurabi, 18th Century B.C.:
If a contractor builds a house for a man and does not build it strong enough, and the house which he builds collapses and causes the death of the house owner, than the contractor shall be put to death.
If it causes the death of the son of the owner, then the son of the contractor shall be put to death.
This is of particular interest to me as I contribute code to software used to design steel buildings. I would not want to see this code reapplied today to dwellings or programming.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
My car is buggy, very buggy by software standards. Here's a list of just a few of it's bugs:
1) It is not resiliant to attacks. If someone wants to break in and steal it, it's very easy to do. Trivially easy to someone with training. The manufacturer has done NOTHING to fix this. In fact, all suggested solutions are just bandaids, they don't really do anything. Stronger glass, a kill switch, the Club, all are easily defeatable. They offer me no absolute security against attacks.
2) My car does not deal with user error very well. If I put it in neutral and floor it, the engine will overheat and seize up, no cut out. If I poot toothpaste in the oil tank instead of oil I'll ruin the engine. There is virtually no protection against me making mistakes, and many of the mistakes will permenatnly disable the car.
3) My car doesn't handle unexpected situations well. If it suddenly hits a brick wall, it will be damaged or destoryed, same if another driver suddenly collides with me. It only operates properly under normal circumstances.
What's worse? They KNEW about all these problems from the car's inception. They sold it to me, knowing these problems, and are doing NOTHING to fix them! Even upgrading to a newer version of my car (for which I must pay full price) won't fix them.
So I feel it absurd to attempt to say "We have to hold software to the same standard as cars" and by that mean that software should be perfect. Cars aren't perfect, by software standards they are buggy peices of shit. I expect that software should be essentially immune to any malicious attacks. If a flaw is found, I expect it fixed in a timely fashion for no charge. Likewise, I expect software to deal with user error well and not blow up if I do something wrong. However if I told you I wanted a car that did all that, I'd be laughed at.
You are correct about tradeoffs. "Perfect is the mortal enemy of good enough." For most software good enough is, well, good enough. Development cost and time-to-market drive decisions much more than ultimate lack of bugs. I realize that 99.9% of all sofware out there is not life and safety critical. Nobody dies if a printer driver crashes. Thus, there is no point, other than pride in ones own craftsmanship, in writing perfect code.
However, a lot of people here have stated that it is flat out impossible to write code with no bugs. Almost as if it were a law of physics, or religious dogma. It is, of course, also a handy excuse for writing buggy software, and a great way to dodge the responsibilty.
It IS possible to write bug free software; I know because that's what I do for a living. We write software for railroad traffic control systems. An unsafe failure can easily lead to dozens of lives being lost. For an analogy, picture an intersection of two busy four-lane highways, where the traffic lights once in a while all go green at the same time.
There simply can't be bugs in our finished software. The procedures and methods we use to ensure this are time consuming and expensive, but we have no choice. And if, God forbid, somebody died because of a bug in my software, then I would be responsible.
None of them can see the clouds; The polished wings don't care.
Ha! Yeah, that'll happen.
Political responsibility is limited by the memory span of the constituents. If we've forgotten by the time of the next election, then they're not held responsible. There are several problems contributing to this:
There are other reasons why politicians' actions are poor.
Constitutionally Correct
Not disagreeing with the sentiment. I've had to deal with my share of "my god this ain't right" code because for a lot of people simply demonstrating that a function CAN get the right results is enough to call it a day.
The problem is us few folk who actually care to do things right at the start usually get pushed aside from the peeps who want a really quick solution. Of course it usually happens that down the road a proper start ends up saving time and money in the end but management doesn't care about that.
For me the best compliment I get is "it just works". As in people use my libraries [and various programs] and they "just work" as advertised [e.g. documented]. People seem to be surprised that I document stuff too [e.g. I have a manually typed/formated manual in LaTeX as well as doxygen comments] as well.
On my part I do things like make rational design choices [e.g. clear function names, consistent parameter orders, return values, expected behavioural models] because *I* want to use the code. The fact that it helps others [the code is public domain] is purely immaterial.
And I think that's the trick. Most "really crappy" software is written by people who
a) don't know better
b) won't be using it themselves in future work [e.g. it works now, I'm done]
c) see a)
Like look at things like some kernel modules. They're for the most part horribly written but that's solely because once it works once they think their job is done.
Then you have a host of really buggy pieces of commercial, shareware, freeware and OSS tools that come from people who bite off more than they chew. They come out of college or university without a single successful project under their belts and they assume they have unquestionable knowledge about the nature of the universe.
What's worse is some of these people turn into 50 yr olds with a chip on their shoulders about a golden yesteryear.
If people just wrote code under the working assumption they'd have to see it again one day you'd see more modular, flexible, well documented and thoroughly tested code. Or they're stupid for inventing more work for themselves...
Tom
Someday, I'll have a real sig.
I agree 100%. I think all companies should be liable for their products. However, I do not think it should be at the individual employee level.
Here's an interesting question. A piece of software that is written to work with Windows has a security flaw in it. The security flaw creates an exploitable condition in Windows such that you can gain total control over the system. Who's fault is it?
Obviously there was a security flaw in the software that you were using, but then it wouldn't be that critical if Windows handled it's security better. So isn't Windows partially to blame. And what if you set it up in an insecure manner? Isn't that your fault? Or is the developer's fault for not making it more idiot proof.
Now taking that down to the code inside of a program is just ridiculous. If you've got a team of 10 people (which is small in the grand scheme), each one of them could, individuall write totally secure code. However, come integration time, it turns out that they are opening up holes in eachother's code. So then who's fault is it? What about QA? Shouldn't they have some liability too?
Finally there's the PHB factor. You could have a group of the best, most security knowledgeable programmers in the world, and they could still screw up due to lack of time and resources. What if the boss tells them to do something that makes the system innately insecure? Who's fault is it then, his for telling them to do it or theirs for not pushing back on the requirement. Not to mention what happens after people have work a few months of 60 hour work weeks trying to get a project done.
In the end, liability is just a dumb concept in computers. In the end this is one of those places where the invisible hand of the market place is the best correction. Companies that write buggy software routinely will be smacked by the marketplace, by and large. The only exception to that rule is companies like Microsoft who have an effective monopoly. But then that's why we have anti-trust law isn't it?
This sig has been temporarily disconnected or is no longer in service
Add to the 'sign-off' aspect the usually required (at least here in Canada) training in law and ethics and you will find that few P.E.s will sign their names or affix their seals to things they don't have relatively high degrees of confidence in. When a P.E. screws up, they lose their license to practice and quite often their businesss, consultancy, or academic credentials at the same time. Thus, they try very hard not to screw up. This means they are act as a check on poor practices.
But getting to be a P.E. involves overcoming the standard challenges and it isn't for everyone. A lot of engineering in non-software fields seems based around working with known processes and known parameters to produce a product or some result.
The reason bridge building is a pretty sane discipline is that the characteristics of materials and the physics of bridges is pretty well explored. When a Civil Engineer builds a bridge (or designs one), he has good computer aided tools to do it, standard catalogs of parts and materials, and he knows all about tolerances, safety factors, and good processes. He couldn't sign-off on the project otherwise, without taking his head in his hands.
Contrast that with my work, where I have to build applications using an OS I know is inherently flawed (they all are, but some more notably), it must be designed to work on a wide variety of hardware platforms (many of which I don't have on hand), it must often work with other people's code from outside my organization which is bleeding edge and often of dubious standards, and it is built with tools I only mostly trust and on top of libraries from the OS provider and from third parties into which I have no visibility. There are strategies to mitigate risk, but I'd be very damn leery of signing my name or affixing my sigil in a P.E. context to even my best code - because I know the system it is part of has so many components I don't control and so many points of failure.
One risk mitigation strategy involves extensive testing (some say up to 90% of project cost). Anyone interested in paying $1500 for a copy of Office? I don't see many hands.
I'm all for seeing an improvement of professional standards and practices in the field, the injection of more engineering approaches into the field, etc. But the software field moves faster (IMO) than any other technical field. It also is one in which you have the least faith in the parts you build with. Until reform happens *across and throughout* the field, any efforts to go after companies or individual engineers is a waste of time.
Let's put it another way, more succinct: If I had to sign off in a legal liability sense for the code I've been writing for the last two years on the current contract, I'd imagine I'd have written about 10% of the code I have written and I'd have demanded a *lot more* from the people supplying me with 3rd party code to integrate. Since I know the business model wouldn't support that (the costs would kill the product as it stands), I have to think this approach is only viable once we decide we don't want 'the next new thing' in software and that we care about what we get enough to pay for it.
Someone compared the effort to Ford or GM making cars. If you want to spend $15-50K dollars for a computer, I'm sure we can offer you a lot higher level reliability from the software. heck, at those kinds of costs, you might get the same sorts of warranties you get from Ford and GM, though they warrant around as much as they can get away with. But if you want to pay under $1000 for the hardware and under $1000 for the principal software, then you might as well expect something that works about 1/10th as well. And it seems to me you've got that.
So, who here is lining up to buy the first $15K personal computer?
Nice idea, don't see it happening anytime soon.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
...Ok, I have donned the flame proof underwear here. And speaking entirely subjectively; well, in reference to Australian Engineering in any case.
:)
Anyway, I am an Engineer, with certified competencies in Australia. I specialise in mechatronic engineering and work mostly in manufacturing systems development. As a highly qualified professional, I can be and indeed am held personally liable for my failures, as can a Medical Doctor. The similarities?? LONG and COMPLEX degrees, sufficient training and sufficiently rigorous oversight that graduates, after an intern period, may be considered legally liable and have the skills and competence to operate in such an environment. Not only that, but I must demonstrate a significant number of hours a year in professional development to maintain my certification. Without it I couldnt get professional indemnity insurance, nor indeed jobs for which I am likely to be held personally liable.
Here in Australia at least, there are NO true Engineering degrees for computer programmers, Electrical or Electronic engineers often specialise in computer systems, but they are still trained as Engineers first and foremost. Degree qualified computer programmers are at best science graduates and at worst arts graduates. It is unreasonable to place the burden of personal liability on people who did not choose such a career path. When I was at university the difference was 35+ contact hours vs 16- contact hours and a 4~5 year degree vs a 3 year degree. Those doing the latter certainly arent likely to be adequately prepared to shoulder that kind of professional burden.
Take a graduate mechatronic Engineer, a mechanical Engineer, a civil Engineer and an aerospace Engineer. Give them each problems from the other's field and appropriate references. They will struggle with unfamiliarity but they WILL be able to competently solve the problem, why?? they are all trained in the same basic principles. Hand a computer "engineer" a fluid dynamics problem and they will almost certainly NOT be able to solve it. They learn to write programs (so do we, actually, in fact, I consider the ability to program essential in graduate Engineers I hire, same as a second language; just important complementary skills, not core skills).
In summary, you cannot start to hold an employee personally liable until the training and development systems that produce them are sufficiently rigorous to ensure that people who graduate into that field are at least theoretically able to take on the responsibility. Furthermore, some strong professional bodies would be required. The kind that require members to continue their professional development to retain certification and, therefore, continue to be considered competent to be held personally liable.
Anyway, not trying to belittle computer "engineers", but I think their training has to step up several levels in rigor and broaden its scope to truly be considered an Engineering discipline before you start laying the burden of personal liability on their shoulders. Essentially, if you couldnt get professional indemnity insurance, you probably shouldnt be able to be held personally liable. Whilst there are very certainly programmers and hackers out there more than competent to be held liable for their work, without a professional structure; there is no sure or reliable means to make that descision or filter people who really aren't able.
Just my $0.02 AUD, apologies to any I offended
err!
jak.
That's pretty moronic. Anyone who works in software security (and has a clue) would never put themselves in a position of being personally liable for certifying a piece of software as being "secure".
Likewise, security consulting companies generally only issue "verifiable statements" regarding the software they evaluate. Such statements can include things like "passwords are not stored in plaintext", or "all network traffic is encrypted with SSL". No company with a clue would risk its business on a blanket guarantee that a piece of software is "secure". That's because there is no way to verify a given application is "secure" in the absolute sense anyway.
Yet Mr Schmidt expects developers to certify as such. He clearly has no clue. While he's at it he should demand that automotive engineers certify their cars will never break down, and that police be held personally liable for failing to prevent a crime.
Scary, but you just described my company's business process. I think it's even documented that way. ;p
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Here is the thing. My car is 20 years old. I'm living in a 40 year old building. The building is warm, and secure. My car runs, and has very little mantinance issues. My 3 year old computer is seriously out of date. If the computer could be garunteed to last for 10+ years, (Even I will admit that 20 years for a car is exceptional) I would have no problem shelling out $15K for it. I think this is where some of the issues come in to play. Every one is so desperate to have the Newest and prittiest, that they arn'd demadning the Best. And companies deliver what the people whant. And don't get me started on the big companies (not just M$, others do the same) that push the New and Pritty, just so they can keep turning large profits. Most of it is the software equivalent of repaining last years modle, and selling it as this years. Yes it looks newer, but it still has that faulty Altenator, that unreliable Fuel line. Eg. Word Perfect 5.1 did everything I use Word 2003 for, So why did I need to buy Word 97, Word 2000, WordXP, and Word 2003. (O.K., I still use Word Perfect 5.1, don't tell anybody, But most people out there know what I am talking about)
sorry, got on a little bit of a rant there.