8 SOFTWARE QUALITY $1.2 Compatibility Definition:compatibility Compatibility is the ease of combining software elements with others. Compatibility is important because we do not develop software elements in a vacuum: they need to interact with each other.But they too often have trouble interacting because they make conflicting assumptions about the rest of the world.An example is the wide variety of incompatible file formats supported by many operating systems.A program can directly use another's result as input only if the file formats are compatible Lack of compatibility can yield disaster.Here is an extreme case: DALLAS-Last week,AMR,the parent company of American Airlines,Inc.,said it fell San Jose (Calif.) on its sword trying to develop a state-of-the-art,industry-wide system that could also Mercury News,July handle car and hotel reservations. 20,1992.Ouoted in AMR cut off development of its new Confirm reservation system only weeks after it was the“comp.risks” supposed to start taking care of transactions for partners Budget Rent-A-Car,Hilton Usenet newsgroup. 13.67,Jl1992. Hotels Corp.and Marriott Corp.Suspension of the $125 million,4-year-old project Slightly abridged. translated into a $165 million pre-tax charge against AMR's earnings and fractured the company's reputation as a pacesetter in travel technology.[... As far back as January,the leaders of Confirm discovered that the labors of more than 200 programmers,systems analysts and engineers had apparently been for naught.The main pieces of the massive project-requiring 47,000 pages to describe-had been developed separately,by different methods.When put together,they did not work with each other.When the developers attempted to plug the parts together,they could not. Different "modules"could not pull the information needed from the other side of the bridge. AMR Information Services fired eight senior project members,including the team leader. [...In late June,Budget and Hilton said they were dropping out. The key to compatibility lies in homogeneity of design,and in agreeing on standardized conventions for inter-program communication.Approaches include: Standardized file formats,as in the Unix system,where every text file is simply a sequence of characters. Standardized data structures,as in Lisp systems,where all data,and programs as well,are represented by binary trees(called lists in Lisp). Standardized user interfaces,as on various versions of Windows,OS/2 and MacOS, where all tools rely on a single paradigm for communication with the user,based on standard components such as windows,icons,menus etc. More general solutions are obtained by defining standardized access protocols to all On abstract data important entities manipulated by the software.This is the idea behind abstract data types types see chapter 6. and the object-oriented approach,as well as so-called middleware protocols such as CORBA and Microsoft's OLE-COM(ActiveX)
8 SOFTWARE QUALITY §1.2 Compatibility Compatibility is important because we do not develop software elements in a vacuum: they need to interact with each other. But they too often have trouble interacting because they make conflicting assumptions about the rest of the world. An example is the wide variety of incompatible file formats supported by many operating systems. A program can directly use another’s result as input only if the file formats are compatible. Lack of compatibility can yield disaster. Here is an extreme case: DALLAS — Last week, AMR, the parent company of American Airlines, Inc., said it fell on its sword trying to develop a state-of-the-art, industry-wide system that could also handle car and hotel reservations. AMR cut off development of its new Confirm reservation system only weeks after it was supposed to start taking care of transactions for partners Budget Rent-A-Car, Hilton Hotels Corp. and Marriott Corp. Suspension of the $125 million, 4-year-old project translated into a $165 million pre-tax charge against AMR’s earnings and fractured the company’s reputation as a pacesetter in travel technology. […] As far back as January, the leaders of Confirm discovered that the labors of more than 200 programmers, systems analysts and engineers had apparently been for naught. The main pieces of the massive project — requiring 47,000 pages to describe — had been developed separately, by different methods. When put together, they did not work with each other. When the developers attempted to plug the parts together, they could not. Different “modules” could not pull the information needed from the other side of the bridge. AMR Information Services fired eight senior project members, including the team leader. […] In late June, Budget and Hilton said they were dropping out. The key to compatibility lies in homogeneity of design, and in agreeing on standardized conventions for inter-program communication. Approaches include: • Standardized file formats, as in the Unix system, where every text file is simply a sequence of characters. • Standardized data structures, as in Lisp systems, where all data, and programs as well, are represented by binary trees (called lists in Lisp). • Standardized user interfaces, as on various versions of Windows, OS/2 and MacOS, where all tools rely on a single paradigm for communication with the user, based on standard components such as windows, icons, menus etc. More general solutions are obtained by defining standardized access protocols to all important entities manipulated by the software. This is the idea behind abstract data types and the object-oriented approach, as well as so-called middleware protocols such as CORBA and Microsoft’s OLE-COM (ActiveX). Definition: compatibility Compatibility is the ease of combining software elements with others. San Jose (Calif.) Mercury News, July 20, 1992. Quoted in the “comp ● risks” Usenet newsgroup, 13.67, July 1992. Slightly abridged. On abstract data types see chapter 6
$1.2 A REVIEW OF EXTERNAL FACTORS Efficiency Definition:efficiency Efficiency is the ability of a software system to place as few demands as possible on hardware resources,such as processor time,space occupied in internal and external memories,bandwidth used in communication devices. Almost synonymous with efficiency is the word"performance".The software community shows two typical attitudes towards efficiency: Some developers have an obsession with performance issues,leading them to devote a lot of efforts to presumed optimizations But a general tendency also exists to downplay efficiency concerns,as evidenced by such industry lore as"make it right before you make it fast"and "next year's computer model is going to be 50%faster anyway". It is not uncommon to see the same person displaying these two attitudes at different times,as in a software case of split personality (Dr.Abstract and Mr.Microsecond). Where is the truth?Clearly,developers have often shown an exaggerated concern for micro-optimization.As already noted,efficiency does not matter much if the software is not correct (suggesting a new dictum,"do not worry how fast it is unless it is also right", close to the previous one but not quite the same).More generally,the concern for efficiency must be balanced with other goals such as extendibility and reusability;extreme optimizations may make the software so specialized as to be unfit for change and reuse. Furthermore,the ever growing power of computer hardware does allow us to have a more relaxed attitude about gaining the last byte or microsecond. All this,however,does not diminish the importance of efficiency.No one likes to wait for the responses of an interactive system,or to have to purchase more memory to run a program.So offhand attitudes to performance include much posturing;if the final system is so slow or bulky as to impede usage,those who used to declare that "speed is not that important"will not be the last to complain. This issue reflects what I believe to be a major characteristic ofsoftware engineering, not likely to move away soon:software construction is difficult precisely because it requires taking into account many different requirements,some of which,such as correctness,are abstract and conceptual,whereas others,such as efficiency,are concrete and bound to the properties of computer hardware. For some scientists,software development is a branch of mathematics;for some engineers,it is a branch ofapplied technology.In reality,it is both.The software developer must reconcile the abstract concepts with their concrete implementations,the mathematics of correct computation with the time and space constraints deriving from physical laws and from limitations of current hardware technology.This need to please the angels as well as the beasts may be the central challenge of software engineering
§1.2 A REVIEW OF EXTERNAL FACTORS 9 Efficiency Almost synonymous with efficiency is the word “performance”. The software community shows two typical attitudes towards efficiency: • Some developers have an obsession with performance issues, leading them to devote a lot of efforts to presumed optimizations. • But a general tendency also exists to downplay efficiency concerns, as evidenced by such industry lore as “make it right before you make it fast” and “next year’s computer model is going to be 50% faster anyway”. It is not uncommon to see the same person displaying these two attitudes at different times, as in a software case of split personality (Dr. Abstract and Mr. Microsecond). Where is the truth? Clearly, developers have often shown an exaggerated concern for micro-optimization. As already noted, efficiency does not matter much if the software is not correct (suggesting a new dictum, “do not worry how fast it is unless it is also right ”, close to the previous one but not quite the same). More generally, the concern for efficiency must be balanced with other goals such as extendibility and reusability; extreme optimizations may make the software so specialized as to be unfit for change and reuse. Furthermore, the ever growing power of computer hardware does allow us to have a more relaxed attitude about gaining the last byte or microsecond. All this, however, does not diminish the importance of efficiency. No one likes to wait for the responses of an interactive system, or to have to purchase more memory to run a program. So offhand attitudes to performance include much posturing; if the final system is so slow or bulky as to impede usage, those who used to declare that “speed is not that important” will not be the last to complain. This issue reflects what I believe to be a major characteristic of software engineering, not likely to move away soon: software construction is difficult precisely because it requires taking into account many different requirements, some of which, such as correctness, are abstract and conceptual, whereas others, such as efficiency, are concrete and bound to the properties of computer hardware. For some scientists, software development is a branch of mathematics; for some engineers, it is a branch of applied technology. In reality, it is both. The software developer must reconcile the abstract concepts with their concrete implementations, the mathematics of correct computation with the time and space constraints deriving from physical laws and from limitations of current hardware technology. This need to please the angels as well as the beasts may be the central challenge of software engineering. Definition: efficiency Efficiency is the ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices