Advanced Distributed Systems

It is a surprise to see how, as years go by, two activities so germane to our discipline, (1) the creation of quality software, and (2) the quality teaching of software construction, and more generally of Computer Science, are surrounded or covered, little by little, by beliefs, attitudes, “schools of thought,” superstitions and fetishes rarely seen in a scientific endeavor. Each day, more people question them less frequently, so that they become “everyday truths” or “standards to observe and demand.” I have the feeling that I am minority in this wave of believers and beliefs, and that my viewpoints are highly unpopular. I dare to express them because I fail to see enough faults in my reasoning and reasons, and because perhaps there exist other “believers” not so convinced about these viewpoints, so that, perhaps, we will discover that “the imperator had no clothes, he was naked.” 1 Myths and Beliefs about the Production of Quality Software This section lists several “general truths,” labeled A, B..., G concerning quality of software, and tries to ascertain whether they are reasonable assertions (“facts,” sustainable opinions) or myths. 1.1 About Measuring Software Quality A. It Is Possible to Measure the Main Attributes that Characterize Good Quality Software. The idea here is that software quality can be characterized by certain attributes: reliability, flexibility, robustness, comprehension, adaptability, modularity, complexity, portability, usability, reuse, efficiency... and that it is possible to measure each of these, and therefore, characterize or measure the quality of the software under examination. To ascertain whether point A is a fact or a myth, let us analyze three facets of it. 1) It is possible to measure above attributes subjectively, asking their opinion to people who have used the software in question. Comment 1. Opinions by Experienced Users Are Reliable. That is, (1) is not a myth, but something real. It is easy to agree that a program can be characterized by above attributes (or similar list). Also, it is convincing that the opinions of a group of F. F. Ramos, H. Unger, V. Larios (Eds.): ISSADS 2004, LNCS 3061, pp. 1-8, 2004. © Springer-Verlag Berlin Heidelberg 2004 2 Adolfo Guzman Arenas qualified users respect to the quality, ergonomics, portability... of a given software are reliable and worth to be taken into account (subjective, but reliable opinions). 2) Another practice is to try to measure above attributes objectively, by measuring surrogate attributes if the real attribute is difficult to measure [Myth B below]. Comment 2. Measuring Surrogate Attributes. To measure the height of a water tank when one wishes to measure its volume, is risky. Objective (accurate) measurements of surrogate attributes may be possible, but to think that these measures are proportional to the real attribute, is risky. “If you can not measure beauty of a face, measure the length of the nose, the color of eyes...” If you can not measure the complexity of a program, measure the degree of nesting in its formulas and equations, and say that they are directly related. More in my comments to Myth B. 3) Finally, instead of measuring the quality of a piece of software, go ahead and measure the quality of the manufacturing process of such software: if the building process has quality, no doubt the resulting software should have quality, too (Discussed below as Myth C). Comment 3. To Measure the Process, instead of Measuring the Product. In old disciplines (manufacturing of steel hinges, leather production, wine production, cooking...) where there are hundred of years of experience, and which are based in established disciplines (Physics, Chemistry...), it is possible to design a process that guarantees the quality of the product. A process to produce good leather, let us say. And it is also possible to (objectively) measure the quality of the resulting product. And to adapt the process, modifying it to fix errors (deviations) in the product quality: for instance, to obtain a more elastic leather. Our problem is that it is not possible to do that with software. We do not know what processes are good to produce good quality software. We do not know what part of the process to change in order, let us say, to produce software with less complexity, or with greater portability. More in my comments to Myth C. B. There Exists a Reliable Measurement for Each Attribute. For each attribute to be measured, there exists a reliable, objective measurement that can be carried out. The idea is that, if the original attribute is difficult to measure,1 measure another attribute, correlated to the first, and report the (second) measurement as proportional or a substitute for the measure of the original attribute. 1. Reliability (reliable software, few errors): measure instead the number of error messages in the code. The more, the less errors that software has. 2. Flexibility (malleability to different usage, to different environments) or adaptability: measure instead the number of standards to which that software adheres. 3. Robustness (few drastic failures, the system rarely goes down): measure through tests and long use (Subjective measurement). 4. Comprehension (ability to understand what the system does): measure instead the extent of comments in source code, and the size of its manuals. 1 Or we do not know how to measure it. Myths, Beliefs and Superstitions about the Quality of Software and of Its Teaching 3 5. The size of a program is measured in bytes, the space it occupies in memory (This measurement has no objection, we measure what we want to measure). 6. Speed of execution is measured in seconds (This measurement has no objection, we measure what we want to measure). 7. Modularity: count the number of source modules forming it. 8. Program complexity (how difficult it is to understand the code): measure instead the level of nesting in expressions and commands (“cyclomatic complexity”). 9. Portability (how easy it is to port a software to a different operating system): ask users that have done these portings (Subjective measurement). 10. Program usability (it is high when the program brings large added value to our work. “It is essential to have it.”): measure the percentage of our needs that this program covers (Subjective measurement). 11. Program reuse: measure how many times (parts of) this program have been used in other software development projects. (Objective measurement, but only obtained in hindsight). 12. Ease of use (ergonomics) characterizes programs that are easy to learn, tailored to our intuitive ways to carry out certain tasks. Measure instead the quantity of screens that interact with the user, and their sophistication. Comment 4. Measuring Surrogate Attributes. These “surrogate measurements” can produce irrelevant figures for the quality that we are really trying to measure. For instance, the complexity of a program will be difficult to measure using point 8, for languages that use no parenthesis for nesting. For instance, it is not clear that a software with long manuals is easier to comprehend (point 4). To measure the temperature of a body when one wants to measure the amount of heat (calories) in it, is incorrect and will produce false results. A very hot needle has less heat that a lukewarm anvil. Comment 5. It is true that in the production of other goods, say iron hinges, is easy to list the qualities that a good hinge must possess: hardness, resistance to corrosion... And it is also easy to objectively measure those qualities. Why is it difficult, then, to measure the equivalent quantities about software? Because hinges have been produced before Pharaohnic times, humankind has accumulated experience on this, and because its manufacture is based on Physics, which is a consolidated science more than 2,000 years old. Physics has defined units (mass, hardness, tensile strength...) capable of objective measurement. More over, Physics often gives us equations (f = ma) that these measurements need to obey. In contrast, Computer Science has existed only for 60 years, and thus almost all its dimensions (reliability, ease of use...) are not susceptible (yet) of objective measurements. Computer Science is not a science yet, it is an art or a craft.2 Nevertheless, it is tempting to apply to software characterization (about its quality, say), methods that belong and are useful in these more mature disciplines, but that are not (yet) applicable in our emerging science. We are not aware that methods that work in leather production, do not work 2 Remember the title of the book “The Art of Computer Programming” of Donald C. Knuth. In addition, we should not be afraid that our science begins as an art or a craft. Visualize Medicine when it was only 60 years old: properties of lemon tea were just being discovered. And physicians talked for a long time of fluids, effluvia, bad air, and witchcraft. With time, our discipline will become a science. 4 Adolfo Guzman Arenas in software creation. Indeed, it is useful at times to talk of software creation, not of software production, to emphasize the fact that software building is an art, dominated by inspiration, good luck... (see Comment 7). 1.2 Measuring the Process instead of Measuring the Product An indirect manner to ascertain the quality of a piece of software, is to review the quality of the process producing it. C. Measuring the Quality of the Process, Not the Product Quality. Instead of measuring the quality of the software product, let us measure the quality of its construction process. To have a good process implies to produce quality software. Comment 6. It is tempting to claim that a “good” process produces good quality software, and therefore, deviations of programmers with respect to the given process should be measured and corrected. The problem here is that it is not possible to say which process will produce good quality software. For instance, if I want