There are a number of reasons why companies who develop software should use Agile. Agile is superior to phase gate approaches like Waterfall in quicker time to market, the practices associated with Agile produce a much higher quality product with less technical debt, maintenance of software (which is the bulk of the SDLC in terms of time and money) is much easier, the engagement of employees is much higher and results in less employee turnover, frequent feedback results in better risk mitigation (to name a few benefits). As I look to the future of software I believe we can begin to add one more thing –protection from software malpractice litigation.
The thought came to mind recently as I was listening to an NPR segment on autonomous automobiles. According to the story, a large segment of the American public is hesitant to trust their safety to autonomous vehicles, even though there are some estimates that cite a potential 80% reduction in traffic fatalities. As human beings we are comfortable with the notion of human error, but find it difficult to find comfort in computer, especially software, errors. We find it especially difficult to accept those that would result in loss of life, even if the average loss of life were greatly reduced. I think that the potential for litigation (and concurrent drag on profits) of such defects is quite high. Not only do I expect software defect litigation to be increased because of autonomous vehicles, the Internet of Things (IOT) and the corresponding explosion in software in all areas of our lives will also create scenarios for increased litigation.
In some research for this article, I unearthed a paper by Cem Kaner that speaks directly to this issue. While I do not possess the legal mind that he does, I believe I can understand the two potential issues of Negligence and Malpractice he outlines. In regard to negligence, he states, “How do we decide whether a product was developed or tested negligently?…A critical issue to keep in mind is that the plaintiff must prove that the failure to use some ‘best practice’ actually caused the defect in the system.” As software becomes ubiquitous, the methods used to create software will begin to be questioned more often. I believe there to be overwhelming evidence that software developed using Waterfall methods tend to result in greater technical debt, and therefore, the possibility for being on the losing end of a lawsuit is greater. In other words, improper development methods that have been (and continue to be used in many places) not only result in greater technical debt, but also will expose companies to more potential lawsuits. Should I ever be called as an expert witness it would cause me no compunction to reveal poor development processes and practices. We have all heard of lawsuits that have been filed, litigated and judgments made for less.
With regards to malpractice, Kaner states, “Before calling for the professionalization of software quality advocates, please consider the problem that we need a solid basis for distinguishing unacceptable from acceptable practices.” Of course, this paper was written back in 1997 so the amount of evidence available for determining unacceptable from acceptable is growing and the evidence is strong that Waterfall development is no longer the best or accepted practice.
My argument is this – most software development is complex. It is a well-established truth that complexity is best attacked through frequent feedback, the kind supplied by the agile methodologies and frameworks, as well as the commonly applied practices associated with XP like pair programming, BDD/TDD, code reviews, etc. Software that has been written using methodologies other than Agile generally result in greater number of defects and higher degree of technical debt. As these things are generally accepted by software development professionals as better ways to produce quality software, companies that do not use Agile will become exposed. Furthermore, studies indicate hours worked beyond about 30-40 per week can result in increased numbers of defects. Companies employing this already counter-productive measure have yet another reason for adhering to the agile principle of sustainable development in avoiding potential litigation.
Perhaps malpractice litigation will not affect the realm of software development as I anticipate, but that does not mean it is not appropriate. In some cases, people who with authority to make decisions regarding software development show a willful ignorance of the nature of software development. I believe their behavior is not only detrimental to the production of quality software and the satisfaction of customers and employees alike, but certainly borders on the realm of malpractice. Maybe the hint of malpractice will incentivize people making software development decisions to treat development and developers in a manner more congruent with the true nature of software development.
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Android | RSS