When a medical professional causes damage to his clients, he can be held legally liable for the suffering caused. When a building collapses because of poor construction, we can go after the builder for reparation. When your defective toaster causes fire, the manufacturer can be held liable. When the car seat-belt fails to function, its maker can be hauled to the court of law.
When quality failures bankrupt other companies regularly, what makes the software vendor get away with it? To add insult to injury, software industry routinely ships product with known bugs. It is acceptable for a programmer to sign off her work with known defects. The defect identified just gets added to a growing list of bugs to be fixed in the next project cycle.
Why not expose the programmer to legal liability for the damages he caused? Will this accountability result in improved software products?
In [CACM April 2009 - A direct path to dependable Software], Daniel Jackson gives a brief survey of software related incidents covering hospitals to medical instruments, and talks about software companies actively suppressing even basic data on the number and severity of bugs in their products. Can a civilized society accept such practices in any industry, leave alone one as crucial as software development?
There are some moves now to hold the software industry more accountable.
Let us look at some arguments both in favor of and against holding the programmer legally liable for delivering defective product.
Point 1: It is impossible to deliver a defect-free software product of reasonable complexity ("Halting Problem"). Also, Quality Control testing cannot catch all possibilities. As Dijkstra famously observed, software tests can only prove the presence of bugs, not their absence.
Counterpoint 1: Liability depends on what could be reasonably expected of the programmer. If the programmer did not follow the prevailing industry standards and make all efforts to deliver correct code, he should be held liable.
Point 2: Bugs are acceptable trade-offs in software delivery. Quality can be traded-off against cost or time. If the bugs identified are deemed non-lethal, the software product can be shipped out. Some bugs may not be even experienced under regular use, rendering them harmless. Delaying the product to fix all arcane bugs will result in competitive disadvantage.
Counterpoint 2: While not all bugs need to be fixed before delivery, those that break any reasonable user expectation should be fixed. Any bug that violates the letter and spirit of user requirements is deemed harmful. Minimally the user should be made aware of any shortfall in writing and his consent obtained before releasing the product with the defect. The developer should be confident that his decision to release the product with known defects will stand scrutiny in a court of law.
Point 3: Defects may not be foreseeable. Software behaviour is heavily influenced by the run time environment. It may be impossible to account for all variations. The combinatorial explosion that would result in certifying the product with other vendor products is insurmountable.
Counterpoint 3: Software products should be driven by clearly defined specifications that identify the typical run time environment. If an user is known to use a set of third-party software products, its acceptable interaction if any should be documented in user requirements. As long as the programmer did not do due diligence in ensuring his product would work under expected use cases, she should be held liable.
Point 4: Penalizing the programmer is counterproductive. No professional deliberately sabotages her own product. This scheme will incentivize the programmer to search for legal loopholes to avoid liability, instead of coding to the best of her abilities.
Counterpoint 4: A programmer aware of her legal liability will be doubly vigilant in her work. Under the current situation where the programmer is treated with kid gloves, code quality is likely to take a back-seat to other priorities.
Point 5: A programmer is naturally oblivious to defects in his own code. It is easy to miss bugs in one's own code, lacking a different frame of mind to inspect it critically.
Counterpoint 5: There is a plethora of tools at the programmer's disposal to help him track and fix the bugs: user sign off on specs, design review, following coding standards, documentation, code review, various test approaches (unit, regression, system, automated, user-acceptance). Following systematic approach is known to result in improved quality. Again, the programmer's legal liability will account for what could be reasonably expected of him, under the existing state of industry.
Point 6: In an industry notorious for a shortage of highly skilled labor, such a burden will drive away prospective employees. As it is, students do not sign up for computer science courses.
Counterpoint 6: In classical Economics, a reduced supply and increased demand results in higher price equilibrium, which will force more participants to enter the supply side. Such supply side concerns should be addressed independently, such as government subsidies to students, and should not be used as an excuse for delivering shoddy work.
Point 7: Market-driven conditions already ensure good software quality. Forcing the programmer to buy insurance for his work will result in that cost being passed on to the customer.
Counterpoint 7: Studies show that the threat of legal liability for shoddy work results in the actors paying attention to defects. A software product should be viewed as a contractual obligation to its end users, and as such be subject to contract law. Markets determine what is an acceptable cost increase for better quality.
Point 8: Software is mostly a collective enterprise. Rarely industry strength products are developed by a lone programmer. It is difficult to identify the programmer responsible for the bug.
Counterpoint 8: As a starting point, the software vendor should be held liable. As all the programmers have a vested interest in their firm avoiding legal liability, this will have the result in delivering better software product.
Point 9: Open-source software is a labor of love, developed by enthusiasts without a financial motive. Legal penalties will shutter this movement down.
Counterpoint 9: Legal liabilities should be ascertained only on commercial software products. This will result in commercial firms underwriting the legal liability of strong open source products. For instance, IBM already offers to cover legal liabilities of Linux from patent infringement suits. This is a win-win situation: open-source is left alone, commercial firms fill the vacuum to provide legal cover and legal liability results in improved software products.
Point 10: Legal liability will result in stifling creativity. Software industry thrives on innovation. Fear of suits will freeze the developer's flow, resulting in contrived products. Many products are conceived without an end-user specification, created by the vision of few creative minds.
Counterpoint 10: All commercial products should satisfy certain reasonable requirements, unlike artworks which are deemed expressions of freedom. In particular, software products that result in harming the society should be held liable.
Point 11: All first generation software products are bound to have bugs, no matter how much effort is spent to avoid it. Products regularly improve on repeated iterations, from real-world experience. Legal penalty for bugs will ensure nothing new ever comes out.
Counterpoint 11: This does not seem to be true from experience in other industries. Car companies regularly introduce new models. Medical instrument makers constantly invest in innovation. Builders try new construction material all the time. In all these cases, they are successfully operating under the threat of legal action for defective products. It is difficult to imagine software industry would be an exception.
Summary: Holding developers legally liable for defective products is definitely on its way. Software industry can ignore this at its own peril.
No comments:
Post a Comment