Getting Developers to Commit

By Peter Coffee  |  Posted 2005-06-01 Print this article Print

to Standards"> 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 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.

    Peter Coffee is Director of Platform Research at, where he serves as a liaison with the developer community to define the opportunity and clarify developersÔÇÖ technical requirements on the companyÔÇÖs evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter companyÔÇÖs first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.

    Submit a Comment

    Loading Comments...
    Manage your Newsletters: Login   Register My Newsletters

    Rocket Fuel