Functionality

                   Functionality is the extent of possibilities provided by a system.One of the most difficult problems facing a project leader is to know how much functionality is enough. The pressure for more facilities, known in industry parlance as featurism is constantly there. Its consequences are bad for internal projects, where the pressure comes from users within the same company, and worse for commercial products, as the most prominent part of a journalist’s comparative review is often the table listing side by side the features offered by competing products.

                    Featurism is actually the combination of two problems, one more difficult than the other. The easier problem is the loss of consistency that may result from the addition of new features, affecting its ease of use. Users are indeed known to complain that all the “bells and whistles” of a product’s new version make it horrendously complex. Such comments should be taken with a grain of salt, however, since the new features do not come out of nowhere: most of the time they have been requested by users other users.What to me looks like a superfluous trinket may be an indispensable facility to you.

             The solution here is to work again and again on the consistency of the overall product, trying to make everything fit into a general mold. A good software product is based on a small number of powerful ideas; even if it has many specialized features,they should all be explainable as consequences of these basic concepts. The “grand plan” must be visible, and everything should have its place in it.

                 This method is tougher to enforce on a day-to-day basis because of the pressures mentioned, but yields a more effective software process and often a better product in the end. Even if the final result is the same, as assumed in the figure, it should be reached sooner.Following the suggested path also means that the decision to release an early version at one of the points marked by colored squares in the figure becomes, if not easier, at least simpler.It will be based on your assessment of whether what you have so far covers a large enough share of the full feature set to attract prospective customers rather than drive them away.

Joys of the Craft

        A programming system component costs at least three times as much as a stand alone program of the same function. The cost may be greater if the system has many components. In the lower right hand corner of  stands the programming systems product. This differs from the simple program in all of the above ways. It costs nine times as much. But it is the truly useful object.

          First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake. The intended product of most system programming efforts. 

         Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."Third is the fascination of fashioning complex puzzle like objects of interlocking moving parts and watching them work in subtle cycles,playing out the consequences of principles built in from the beginning. 

        The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate. Fourth is the joy of always learning, which springs from the non repeating nature of the task. In one way or another the problem is ever new, and its solver learns something  sometimes practial, sometimes theoretical, and sometimes both.

Extendibility

Extendibility is the ease of adapting software products to changes of specification.Software is supposed to be soft, and indeed is in principle; nothing can be easier than to change a program if you have access to its source code. Just use your favorite text editor. The problem of extendibility is one of scale. For small programs change is usually not a difficult issue; but as software grows bigger, it becomes harder and harder to adapt.

         A large software system often looks to its maintainers as a giant house of cards in which pulling out any one element might cause the whole edifice to collapse. We need extendibility because at the basis of all software lies some human phenomenon and hence fickleness. The obvious case of business software,where passage of a law or a company’s acquisition may suddenly invalidate the assumptions on which a system rested, is not special; even in scientific computation, where we may expect the laws of physics to stay in place from one month to the next, our way of understanding and modeling physical systems will change.

             Traditional approaches to software engineering did not take enough account of change, relying instead on an ideal view of the software lifecycle where an initial analysis stage freezes the requirements, the rest of the process being devoted to designing and building a solution. This is understandable: the first task in the progress of the discipline was to develop sound techniques for stating and solving fixed problems, before we could worry about what to do if the problem changes while someone is busy solving it. 

               But now with the basic software engineering techniques in place it has become essential to recognize and address this central issue. Change is pervasive in software development:change of requirements, of our understanding of the requirements, of algorithms, of data representation, of implementation techniques. Support for change is a basic goal of object technology and a running theme through this book.

Software Quality

                      Engineering seeks quality; software engineering is the production of quality software.This book introduces a set of techniques which hold the potential for remarkable improvements in the quality of software products.Before studying these techniques, we must clarify their goals. Software quality is best described as a combination of several factors. This chapter analyzes some of these factors, shows where improvements are most sorely needed, and points to the directions where we shall be looking for solutions in the rest of our journey.

                  We all want our software systems to be fast, reliable, easy to use, readable, modular, structured and so on. But these adjectives describe two different sorts of qualities.On one side, we are considering such qualities as speed or ease of use, whose presence or absence in a software product may be detected by its users. These properties may be called external quality factors.

              Under “users” we should include not only the people who actually interact with the final products, like an airline agent using a flight reservation system, but also those who purchase the software or contract out its development, like an airline executive in charge of acquiring or commissioning flight reservation systems. So a property such as the ease with which the software may be adapted to changes of specifications defined later in this discussion as extendibility falls into the category of external factors even though it may not be of immediate interest to such “end users” as the reservations agent.

             Other qualities applicable to a software product, such as being modular, or readable, are internal factors, perceptible only to computer professionals who have access to the actual software text.In the end, only external factors matter. If I use a Web browser or live near a computer-controlled nuclear plant, little do I care whether the source program is readable or modular if graphics take ages to load, or if a wrong input blows up the plant. But the key to achieving these external factors is in the internal ones: for the users to enjoy the visible qualities, the designers and implementers must have applied internal techniques that will ensure the hidden qualities.

Programming Systems

        No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the mind's eye one sees dinosaurs, mammoths, and sabertoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar.  

           Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems few have met goals, schedules, and budgets. Large and small, massiveor wiry, team after team has become entangled in the tar.

           No onething seems to cause the difficulty any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it. 

          But we must try to understand it if weteam after team has become entangled in the tar are to solve it. Therefore let us begin by identifying the craft of system programming and the joys and woes inherent in it.beast is so strong or so skillful but that he ultimately sinks.

Timeliness

               Timeliness is the ability of a software system to be released when or before its users want it.Timeliness is one of the great frustrations of our industry. A great software product that appears too late might miss its target altogether. This is true in other industries too, but few evolve as quickly as software.Method promotes a common design style and standardized module and system interfaces, which help produce systems that will work together.

                        Timeliness is still, for large projects, an uncommon phenomenon. When Microsoft announced that the latest release of its principal operating system, several years in the making, would be delivered one month early, the event was newsworthy enough to make the frontpage headline of ComputerWorld.O-O techniques enable those who master them to produce software faster and at less cost; they facilitate addition of functions, and may even of themselves suggest new functions to add.

                 The contribution of O-O tools to modern interactive systems and especially their user interfaces is well known, to the point that it sometimes obscures other aspects.Although the extra power or object-oriented techniques at first appears to carry a price, relying on professional-quality reusable components can often yield considerable performance improvements.Because of this closeness of correctness and robustness issues, it is convenient to use a more general term, reliability, to cover both factors.

                   With its emphasis on abstraction and information hiding, object technology encourages designers to distinguish between specification and implementation properties, facilitating porting efforts. The techniques of polymorphism and dynamic binding will even make it possible to write systems that automatically adapt to various components of the hardware software machine, for example different window systems or different database management systems.

Efficiency

             Efficiency is the ability of a software system to place as few demands aspossible 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 fifity percent faster anyway”.

            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.An in-flight computer must be prepared to detect and process a message from the throttle sensor fast enough to take corrective action.

               The concern for efficiency will be there throughout. Whenever the discussion presents an object-oriented solution to some problem, it will make sure that the solution is not just elegant but also efficient; whenever it introduces some new O-O mechanism, be it garbage collection, dynamic binding, genericity or repeated inheritance, it will do so based on the knowledge that the mechanism may be implemented at a reasonable cost in time and in space.Efficiency is only one of the factors of quality; we should not let it rule our engineering lives. But it is a factor, and must be taken into consideration, whether in the construction of a software system or in the design of a programming language. If you dismiss performance, performance will dismiss you