Software standards used to be developed by programmers, for programmers, as tools for ensuring interoperability and achieving greater leverage for developers skills.
Increasingly, though, development teams find their efforts affected by standards that respond to external forces, such as corporate governance regulators, consumer protection activists, civil rights advocates, and other stakeholders and scrutineers.
Development teams must expand the sweep of their radar to become aware of new strictures and to allocate time, invest in training and incorporate appropriate conformance tools into their work.
Software development is coming late to the standards party. Industry and commerce take place in environments pervaded by all manner of standards.
Included by reference in contracts, enforced in many situations with the power of criminal law and taken for granted by customers in any reputable place of business, its these detailed public definitions of acceptable practice that make it possible to exchange complex products and services—without making every customer individually responsible for expensive and redundant inspections and certifications.
Both developers and users suffer from the present limited scope and power of comparable software standards. They grapple with mutual hostility and incur unnecessary costs due to lack of mutually understood obligations—those of the developer to offer a reliable product and those of the buyer to define what purchased software needs to do.
Software as product
If a piece of pipe is labeled as conforming to a particular grade of material or an electrical component is labeled as being safe for use at a certain voltage, these are objective statements. Software function and performance measurements, in contrast, are notoriously difficult to reproduce even in a single artificial test environment, let alone in a way thats meaningful to typical users in real-world situations.
Finding it difficult to certify software to the kind of standard associated with an Underwriters Laboratories Inc. tag or an ASTM (American Society for Testing and Materials) International marking, software sellers have notoriously taken refuge in contract law to shield themselves from buyer expectations. Software often is surrounded by lawyerly EULAs (end-user license agreements) that have become infamous for their evasions of responsibility.
Some such EULA clauses are eyebrow-raising but pose little actual impediment to everyday use. An oft-quoted passage from the Java licensing agreement, for example, demands, “You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility.”
Most software users would probably find this a reasonable warning: Anyone buying software for a task as complex and risky as managing a nuclear power plant should accept the burden of verifying the softwares adequacy to that task or surrounding an external providers general-purpose software with task-specific safety systems.
Users may be less comfortable with the sweeping language—assuming theyve ever even read it—of Microsofts Windows XP Home Edition license.
In very small part this states (with capitals from the original) that “Microsoft and its suppliers provide the Software … AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, whether express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence.”
Faced with such comprehensive denials that the software they buy will do anything useful, buyers turn to consumer protection agencies to place bounds on such evasion.
In fact, to the extent that software is a product and is provided with a written warranty at all, most of the disclaimers quoted above are simply inoperative in the United States under the Magnuson-Moss Warranty Act. State laws can also limit such disclaimers. (Those who advocate purchasing software as a service may be surprised to find that consumer protections for service transactions are often far weaker.)
Rather than paying lawyers to write long exclusion statements that state and federal laws can nullify, a development team may do much better to put a fraction of that effort into devising a warranty that actually means something.
Long overdue are specific statements as to the functions that a piece of software is intended to perform, the requirements that a customer must meet to keep that warranty in effect and the recourse that a customer will have in the event that this commitment is not met.
Getting Developers to Commit
Software as place
Enterprise and public-sector buyers have other levers they can use to pry commitment from third-party developers.
Most large companies already incorporate voluminous conditions in their purchase agreements, specifying everything from materials to be used in a product to the conditions under which that product will be manufactured.
Those responsible for software purchases should be at least as familiar with the bodies of codified software practice that they can readily incorporate by reference into purchase orders. Developers should learn to look for these requirements and to understand their import.
Software accessibility for users with physical limitations, for example, would be costly to define on a sale-by-sale basis but can be specified by reference to the 1998 Amendment to Section 508 of the Rehabilitation Act.
Vendors comply with this requirement by means that include adding text-based, screen-reader-accessible command interfaces in addition to any visual symbols, as well as by adding user preference settings for colors and other visual cues that make software usable to those with impairments such as color blindness.
Developers, in turn, pave the way for satisfaction of these requirements by conforming to platform rules for use of menu frameworks, keyboard shortcuts, preference settings and other user interface standards rather than devising a differentiated user interface that turns out to be much more costly to adapt.
Its tempting to extend this argument and suggest that many software-based offerings, such as Web sites, are effectively “public accommodations” under laws such as the ADA (Americans with Disabilities Act)—that just as buildings must have wheelchair ramps and Braille markings on elevator buttons, so must public-facing computer applications serve those with special needs.
Courts have so far tended to rule, though, that the ADAs provisions apply to a physical place, not cyberspace. The Southwest Airlines Co. Web site provided a notable test case in 2002.
Developers should nonetheless take the lead in urging that enterprise software be designed and deployed in ways that maximize its ability to make data and function available to the broadest possible variety of users across a universe of devices.
More broadly, developers should expect that the scope and the potency of externally imposed standards will have a growing influence on their efforts. Today, a building contractor that saves money with undersized electrical wiring will face significant penalties—not merely those defined by a contract clause but even criminal prosecution. An equally skimpy job of software construction faces little in the way of competent inspection, let alone meaningful consequence for incompetence or deception. That disparity is bound to change.
The software industry has become infamous for its ability to extract extra fees from customers as the price of merely meeting their initial expectations. But IT buyers and individual consumers have gotten over their 1960s astonishment that computers even exist or their 1980s delight in discovering a computer on every desk and a microprocessor in every device.
The major IT task of the 2000s, likely to continue into the next 10 to 15 years, is to bring to software development and deployment the kind of reliability, consistency and enforceable level of quality thats needed in such a fundamental component of life and work.
Technology Editor Peter Coffee can be reached at [email protected]
Standards for Software Face Difficult Definition
- A lack of reproducible tests and limited success of legal analogies challenge developers and buyers.
- Sweeping disclaimers of implied warranty mean little.
- Buyers should include task descriptions and define acceptance tests in purchase documents.
- Developers should disclose product limitations clearly.
- The distinction between product and service may be crucial.
- Software should be treated whenever possible as part of a more general product or service, not as a separate entity.
Source: eWEEK Labs
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.