From Byte Wars: The Impact of September 11 on Information Technology

by Edward Yourdon • Prentice Hall PTR, Upper Saddle River, NJ, 2002

But for the vast majority of business organizations, the discussion about the tradeoffs and compromises of a good-enough system have assumed that the system would operate in a relatively benign environment. In particular, we’ve assumed that software defects would represent an inconvenience or disruption in the day-to-day activities of end-users who were trying to use the system to carry out its intended purpose. Not only that, we’ve assumed that whatever defects remain in a system, after we’ve accomplished a good-enough degree of testing, will be relatively obscure, and will probably be associated with features and situations that occur only rarely.

But in today’s world of terrorists and hackers, we must assume that at least some of our users make a deliberate effort to find the defects—not to write a critical review in a computer trade magazine, but to exploit the defect to circumvent the systems security and protection mechanisms or to cause a system crash, or to cause the destruction or corruption of the system’s database. Thus, the determination of a good-enough balance between functionality, cost, speed of development, and defects must now take into account the likelihood that some of the users will deliberate and aggressively look for ways to mis-use the system. [p. 239]

From Machine Beauty: Elegance And The Heart Of Technology

by David H. Gelernter, Professor of Computer Science at Yale University • Basic Books, New York, 1997

... the physical analogy on which the Macintosh operating system is based also creates a problem we might call “paradigm drag.” Kay himself refers to exactly this issue when he writes, about folders, that “one of his longstanding pet hates” is to have them “behave anything like their physical counterparts.” The electronic desktop inevitably lacks certain good properties that all physical desktops have. It counters with advantages that physical desktops lack; but the drag effect comes in when the electronic version is cramped by the limitations of the physical one. No physical desktop can do something or other, and as a result it doesn’t occur to software designers to give that property to the electronic version, either. Basing software on a familiar physical system is a strategy that cuts both ways. [p. 89]

...the national annual cost estimates of an inadequate infrastructure for software testing are estimated to be $59.5 billion. The potential cost reduction from feasible infrastructure improvements is $22.2 billion. This represents about 0.6 and 0.2 percent of the U.S.’s $10 trillion dollar GDP, respectively. Software developers accounted for about 40 percent of total impacts, and software users accounted for the about 60 percent.

___________________________

“Gary Chapman, director of the 21st Century Project at the University of Texas, noted that ‘repeated experiences with software glitches tend to narrow one’s use of computers to familiar and routine. Studies have shown that most users rely on less than 10 percent of the features of common programs as Microsoft Word or Netscape Communicator’” (Barron, 2000).

Planning Report 02-3
The Economic Impacts of Inadequate Infrastructure for Software Testing
Prepared by: RTI
for
National Institute of Standards & Technology
Program Office Strategic Planning and Economic Analysis Group
May 2002

From The Unfinished Revolution: Human-Centered Computers And What They Can Do For Us.

by the late Michael L. Dertouzos, Director of the MIT Laboratory for Computer Science • HarperCollins, New York, 2001

… Big, clunky programs everywhere try to do a lot more than they should, in an effort to maximize their market. I’m sure you have a few you’d like to rage about. The result is confusion and very often the unjustified sense that you, the individual, are inadequate in your ability to use “modern” technology. We should all revolt and ask why people of our stature and ability should have so much trouble using a program that is touted by its maker as “user friendly” (grrrrr, for the last time, bordering on violence). [p. 126]

Today’s operating systems, such as Mac OS, Linux, and Windows, offer from a few hundred to a few thousand such calls to the application programs that run on them. These calls, taken together, form the operating system’s applications interface, or API. The API doesn’t stand still. New calls are introduced in new versions of an operating system to offer new capabilities. And because it is easy to make calls to these system routines, applications programmers are motivated to exploit the new capabilities of the API in new versions of their applications. To be sure, these new features may not always be useful, but they look good on the spec sheet and advertisements. Useful or not, the calls provided by an operating system penetrate all the applications that run on it, and give them a certain common character and feel, which makes us say, “this looks like a Mac application.”

Unfortunately, in the four decades we’ve been using operating systems, their APIs have not risen much toward the human level. There is a myriad of low-level calls in today’s operating systems—things like “close this window,” “put this window in front of that window,” “redraw this window’s contents because the user moved the window hiding it” . . . just to pick on a handful of window management calls. Because applications reflect the underlying system capabilities, it is no wonder that when we are in the middle of some specialized activity, an application suddenly and stubbornly refuses to redraw or move a window. …

…To be fair, innovations in ease of use were made through the introduction of graphical user interfaces (GUIs) with their windows, icons, and menus. And even though these changes were modest, they evoked enthusiastic reactions from users, because they were so much easier than the old text-only approaches.

Such a revision must take place once again, but at a far more ambitious level, to bring applications closer to the level of what people want to do. The information technology terrain has changed sufficiently to warrant the design of such new operating systems. To succeed, these systems should be built from scratch, with a mind-set rooted in people’s paramount need for greater ease of use and increased human productivity. In other words, they must include full support for the five basic human-centric forces, through a new and powerful set of calls to handle speech, automation, information access, collaboration, and customization. And they must support a new information model that is meaning oriented…

The applications interface of computer operating systems must rise from its current machine orientation to a user orientation by exposing to users and applications alike the human-centric technologies. That is the most important foundation software makers can construct and application programmers can exploit to make human-centric computing a reality. Only then will application programs be freed from the low-level machine shackles of today’s computers and soar to new plateaus of human utility.” [pp. 131-133]

From Will Software Ever Work in Communications of the ACM, March 2001,/Vol. 44, No. 3, pp.122-124

by Henry Lieberman and Christopher Fry

It may sound silly to say, but software will work only if we provide the tools to fix it when it goes wrong. Right now, we don’t.

We see an important new direction in providing end-user debugging tools. Users themselves will be able to use them to fix or improve their software. Its’s crazy that at any moment we can’t ask a computer: “What are you doing?” or “Why did you do that?”…

___________________________

Just because most software users are end users rather than programmers doesn’t mean the public shouldn’t be concerned about tools for developers. The quality of debugging tools for developers has a direct effect on the quality of the resulting software; if developers can’t find and fix bugs, the software can’t improve quickly enough.

___________________________

Debugging tools are the instrument panel of the programming environment. But good tools need the foundation of a programming language designed to be debuggable. The language should be dynamic (everything easily changeable at any time) and introspective (extensive access to its own internal workings). One reason debugging hasn’t progressed further in recent years is that programmers have been stuck in undebuggable languages like C and C++ in the name of efficiency.