Getting Developers to Commit
to Standards"> Software as placeMost 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 penaltiesnot 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 firstname.lastname@example.org. 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.
Enterprise and public-sector buyers have other levers they can use to pry commitment from third-party developers.