A reader writes concerning the software warranty debate:
Does this put developers/coders on the hot seat?
For those entities that can credibly be sued, by which I mean corporate entities that take money for their products, the heat has to begin right at the top with the people who make the priorities – the CEO and his team. They have to make it abundantly clear to the product managers that producing and selling a product which will damage the credibility and profitability of their companies is no longer acceptable. I word this paragraph this way as Chong did not address the question of free, open-source software, an area in which I once dabbled. I’ve been out of touch with that area for 20 years, and for the 15 I did dabble, I didn’t communicate with fellow open source authors much at all. These days I really have no idea what is motivating open source authors, to what standards they work, etc. Until I froze updates on my current home computer, which runs Linux/Fedora, I noticed that occasionally an update would cause my system to crash frequently; I can only assume that a flawed enhancement or bug fix had gotten loose into the wild, so it appears testing remains a challenge.
Developers will ultimately be responsible for implementations of technologies and processes that address warranty requirements, of course, but it’s their managers that have to reallocate resources to accomplish the required goals.
My suspicion is that the first step will be to disabuse a lot of developers of the notion that their favorite computer language – or only language they know – can be used for warrantied software. The development costs associated with warrantable work in C, C++, and quite a few others, possibly even including Java, will be devastating.
There’s a couple of aspects to this. First, I would expect there would be a push for provably correct software. This is software that has been subjected to mathematical examination that proves the software does what requirements specify, and nothing more – no nasty side effects, timing issues. Provably correct requires that the requirements be specified in a mathematical manner so that mathematical techniques may be applied to discover problems. There’s been some work done in this area by … Microsoft, I think. I recall blogging about this once, but I don’t recall any keywords. It was getting quite the tout from someone, but it doesn’t appear to have successfully invaded the industry. Which may simply mean software shops are insular.
But, in general, mathematicians hate side effects, and that leads to the second aspect of this work: are we programming machines, or are we developing solutions to problems? These are two very different things, and it’s often difficult to find someone who can do both well. Primitive languages such as machine language and assembly language are the quintessential computer programming languages; C, my milk language, is little more than a portable assembly language that puts a bit of grout over the ugly parts. C++ attempts to jump to object-oriented language while retaining its C roots, a decision that allows the worst aspects of both worlds to persist.
My view is that compilers are potentially the bridge between the two worlds. They are, in essence, a collection of wisdom concerning how to program a computer with a given architecture; the language(s) a compiler supports then become the languages with which we express anything from problems to solutions.
If you’re wrinkling your brow, there actually have been a few languages in which the problem is articulated, and the “compiler” is responsible for taking that articulation and forming a solution. I’m thinking of PROLOG, in which I’ve never worked but covered in a computer course. I’m not absolutely certain skilled practicioners of the language would initially agree with my characterization of a language I learned about 40 (oh god) years ago. Hah!
As noted, not all languages are good for solution composition. C, C++, and other languages which permit side effects which can affect future computations are difficult, or impossible to “prove” correct. Worse, their relatively low support for engineers by closing off the use of techniques that have proven dubious, which many programmers resent, makes them less than useful for producing warrantable work.
I wish I could say I expect that languages in the functional programming paradigm, which refers to mathematical functions and not to alternate meanings, might come into stronger use, but I don’t have enough exposure to the general currents in programming-land to actually make a credible guess. The sharks in this ocean, if I may continue this metaphor, consist of monied interests who are less interested in finding optimal solutions and more in making money. Big conferences, processes such as Agile (which I’m told was used in development of the Minnesota DMV’s recent utter debacle of a computer system), new languages, consultants, they all have a hand and an interest, overt or covert, in their favored solutions. So while I think functional programming languages, which appear to be more amenable to producing provably correct, and therefore warrantable, software, may be the best approach going forward, I’m not aware of any interests capable of the necessary capitalization to thrust them forward into the spotlight for proper evaluation. I myself wonder about their utility when it comes to very large data processing tasks. My experience in this family of languages is limited to Mythryl.
