Dr. Dobb's Journal January, 2005
Licensing Requirements
Dear DDJ,
Jonathan Erickson's June 2003 "Editorial" was pretty good, but I thought no more of the matter until I read Brent Fulgham's formidable counter in the August DDJ.
If a licensing requirement is imposed upon software practitioners in the manner described, we might as well amend Brent's Fulgham's statement in his second paragraph to:
Most of us take for granted that the bridges we drive on, the airplanes we fly in, the medicines we use in our lives, and the Space Shuttles we as taxpayers pay for are safe, reliable, and cost effective, the products of careful design and peer review.
Some may think I am being unfair, but I'm not. First, most people in information technology today do not design or write code from the ground up, as Brent seems to think. We write code to work with other software and software systems, adapt them, or enhance them. It is a mark of early 21st century software practice that we have no specifications for these systems. Those we do have, even if informal, are often inconsistent with how the software actually behaves. That behavior is discovered in debugging our own. Since any practical licensing requirement will necessarily grandfather existing software, holding new code to the more stringent requirement is ridiculous.
Second, I do not know where Brent has been for 10 years, but the software industry has transformed in that time to one where cost and speed to delivery are paramount, and the primary means of achieving that has been to adopt shrinkwrap packages everywhere. This means businesses and institutions, which once employed their own programming staff, no longer have much of a DP or IT staff—they're called "analysts," and their jobs are to specify, procure, install, and superficially maintain products bought off the shelf. This has been the business response and solution to the long recognized problem of software reliability. Business people got impatient awaiting the fruits of software innovation and found their preconditions intolerable. They fixed the problem by amortizing the cost of development over many customers and adapting their practices and business policies to the limited capabilities of existing packages. Software is unpredictable and it is simply not something most of them consider near or pertinent to their core business. Where custom software is needed, outsourcing is the new way, including outsourcing using non-U.S. teams. Requiring licenses of software professionals in the U.S. will simply accelerate this trend. Brent and the Texas Society of Professional Engineers don't seriously expect they can impose this requirement on all software used in the U.S., irrespective of origin, do they?
Third, as attractive as many of the high-precision techniques for designing and developing software are, such as Design By Contract and similar methods, they are inadequate because they expect detailed and accurate specifications to be available for software to be developed. While there are methods available in approaches like Extreme Programming for mitigating some of these demands, business people, end users, and functional users are simply not used to working this way. When building business intensive, detailed software, such as enterprise reporting systems or systems which demand the explication of "business rules," it is clear, these people do not understand or know how they themselves or their departments do what they do in the sense of being able to describe it with large amounts of precise detail. Yet, nonetheless, they can do these tasks well and can even teach others to do them well. This means, in the end, that the specification of such software requires developers or their surrogate to adjust its function in response to end-user critiques, complaints, and bug reports, even if the origin of their dissatisfaction has nothing at all to do with the software's implementation, being, for instance, a result of incorrect expectations or documentation regarding the nature of, say, data being fed it from some remote database.
Under these conditions, ideas of software blueprints, precise legal accountability, or even of standards of quality are meaningless. The edifices are being built on shifting sands. This is not a desirable set of circumstances and I am not trying to argue that they are. But it is what business and users feel they need to be successful and, if we want to be successful practitioners of the software art, we need to understand its limitations and serve them using what's there and what we know. Demanding some hypothetical and unrealistic set of terms and conditions will not do it.
Jan Theodore Galkowski
disneylogic@fastmail.fm
DDJ