$4.4 NON-TECHNICAL OBSTACLES 77 It is hard not to think here of the many engineering disciplines that used to be heavily labor-intensive but became industrialized,that is to say tool-based-with painful economic consequences for companies and countries that did not understand early enough what was happening.To a certain extent,object technology is bringing a similar change to the software trade.The choice between people and tools need not,however,be an exclusive one.The engineering part of software engineering is not identical to that of mass-production industries;humans will likely continue to play the key role in the software construction process.The aim of reuse is not to replace humans by tools(which is often,in spite of all claims,what has happened in other disciplines)but to change the distribution of what we entrust to humans and to tools.So the news is not all bad for a software company that has made its name through its consultants.In particular: In many cases developers using sophisticated reusable components may still benefit from the help ofexperts,who can advise them on how best to use the components. This leaves a meaningful role for software houses and their consultants. As will be discussed below,reusability is inseparable from extendibility:good reusable components will still be open for adaptation to specific cases.Consultants from a company that developed a library are in an ideal position to perform such tuning for individual customers.So selling components and selling services are not necessarily exclusive activities;a components business can serve as a basis for a service business. More generally,a good reusable library can play a strategic role in the policy of a successful software company,even if the company sells specific solutions rather than the library itself,and uses the library for internal purposes only.If the library covers the most common needs and provides an extendible basis for the more advanced cases,it can enable the company to gain a competitive edge in certain application areas by developing tailored solutions to customers'needs,faster and at lower cost than competitors who cannot rely on such a ready-made basis. Accessing components Another argument used to justify skepticism about reuse is the difficulty of the component management task:progress in the production of reusable software,it is said,would result in developers being swamped by so many components as to make their life worse than if the components were not available. Cast in a more positive style,this comment should be understood as a warning to developers ofreusable software that the best reusable components in the world are useless if nobody knows they exist,or if it takes too much time and effort to obtain them.The practical success ofreusability techniques requires the development of adequate databases of components,which interested developers may search by appropriate keywords to find out quickly whether some existing component satisfies a particular need.Network services must also be available,allowing electronic ordering and immediate downloading of selected components
§4.4 NON-TECHNICAL OBSTACLES 77 It is hard not to think here of the many engineering disciplines that used to be heavily labor-intensive but became industrialized, that is to say tool-based — with painful economic consequences for companies and countries that did not understand early enough what was happening. To a certain extent, object technology is bringing a similar change to the software trade. The choice between people and tools need not, however, be an exclusive one. The engineering part of software engineering is not identical to that of mass-production industries; humans will likely continue to play the key role in the software construction process. The aim of reuse is not to replace humans by tools (which is often, in spite of all claims, what has happened in other disciplines) but to change the distribution of what we entrust to humans and to tools. So the news is not all bad for a software company that has made its name through its consultants. In particular: • In many cases developers using sophisticated reusable components may still benefit from the help of experts, who can advise them on how best to use the components. This leaves a meaningful role for software houses and their consultants. • As will be discussed below, reusability is inseparable from extendibility: good reusable components will still be open for adaptation to specific cases. Consultants from a company that developed a library are in an ideal position to perform such tuning for individual customers. So selling components and selling services are not necessarily exclusive activities; a components business can serve as a basis for a service business. • More generally, a good reusable library can play a strategic role in the policy of a successful software company, even if the company sells specific solutions rather than the library itself, and uses the library for internal purposes only. If the library covers the most common needs and provides an extendible basis for the more advanced cases, it can enable the company to gain a competitive edge in certain application areas by developing tailored solutions to customers’ needs, faster and at lower cost than competitors who cannot rely on such a ready-made basis. Accessing components Another argument used to justify skepticism about reuse is the difficulty of the component management task: progress in the production of reusable software, it is said, would result in developers being swamped by so many components as to make their life worse than if the components were not available. Cast in a more positive style, this comment should be understood as a warning to developers of reusable software that the best reusable components in the world are useless if nobody knows they exist, or if it takes too much time and effort to obtain them. The practical success of reusability techniques requires the development of adequate databases of components, which interested developers may search by appropriate keywords to find out quickly whether some existing component satisfies a particular need. Network services must also be available, allowing electronic ordering and immediate downloading of selected components
78 APPROACHES TO REUSABILITY $4.4 These goals do raise technical and organizational problems.But we must keep things in proportion.Indexing,retrieving and delivering reusable components are engineering issues,to which we can apply known tools,in particular database technology;there is no reason why software components should be more difficult to manage than customer records,flight information or library books. Reusability discussions used to delve forever into the grave question "how in the world are we going to make the components available to developers?".After the advances in networking of the past few years,such debates no longer appear so momentous.With the World-Wide Web,in particular,have appeared powerful search tools(AltaVista, Yahoo...)which have made it far easier to locate useful information,either on the Internet or on a company's Intranet.Even more advanced solutions (produced,one may expect, with the help of object technology)will undoubtedly follow.All this makes it increasingly clear that the really hard part of progress in reusability lies not in organizing reusable components,but in building the wretched things in the first place. A note about component indexing On the matter of indexing and retrieving components,a question presents itself,at the borderline between technical and organizational issues:how should we associate indexing information,such as keywords,with software components? The Self-Documentation principle suggests that,as much as possible,information “Self-Documenta- about a module-indexing information as well as other forms of module documentation tion",page 54. -should appear in the module itself rather than externally.This leads to an important requirement on the notation that will be developed in part C of this book to write software components,called classes.Regardless of the exact form of these classes,we must equip ourselves with a mechanism to attach indexing information to each component. The syntax is straightforward.At the beginning of a module text,you will be invited to write an indexing clause of the form indexing More details in“n- index wordl:value,value,value... dexing clauses", page 890. index word2:value,value,value... ..Normal module definition(see part C)... Each index word is an identifier;each value is a constant (integer,real etc.),an identifier,or some other basic lexical element. There is no particular constraint on index words and values,but an industry,a standards group,an organization or a project may wish to define their own conventions. Indexing and retrieval tools can then extract this information to help software developers find components satisfying certain criteria. As we saw in the discussion of Self-Documentation,storing such information in the module itself-rather than in an outside document or database-decreases the likelihood of including wrong information,and in particular of forgetting to update the
78 APPROACHES TO REUSABILITY §4.4 These goals do raise technical and organizational problems. But we must keep things in proportion. Indexing, retrieving and delivering reusable components are engineering issues, to which we can apply known tools, in particular database technology; there is no reason why software components should be more difficult to manage than customer records, flight information or library books. Reusability discussions used to delve forever into the grave question “how in the world are we going to make the components available to developers?”. After the advances in networking of the past few years, such debates no longer appear so momentous. With the World-Wide Web, in particular, have appeared powerful search tools (AltaVista, Yahoo…) which have made it far easier to locate useful information, either on the Internet or on a company’s Intranet. Even more advanced solutions (produced, one may expect, with the help of object technology) will undoubtedly follow. All this makes it increasingly clear that the really hard part of progress in reusability lies not in organizing reusable components, but in building the wretched things in the first place. A note about component indexing On the matter of indexing and retrieving components, a question presents itself, at the borderline between technical and organizational issues: how should we associate indexing information, such as keywords, with software components? The Self-Documentation principle suggests that, as much as possible, information about a module — indexing information as well as other forms of module documentation — should appear in the module itself rather than externally. This leads to an important requirement on the notation that will be developed in part C of this book to write software components, called classes. Regardless of the exact form of these classes, we must equip ourselves with a mechanism to attach indexing information to each component. The syntax is straightforward. At the beginning of a module text, you will be invited to write an indexing clause of the form indexing index_word1: value, value, value… index_word2: value, value, value… … … Normal module definition (see part C) … Each index_word is an identifier; each value is a constant (integer, real etc.), an identifier, or some other basic lexical element. There is no particular constraint on index words and values, but an industry, a standards group, an organization or a project may wish to define their own conventions. Indexing and retrieval tools can then extract this information to help software developers find components satisfying certain criteria. As we saw in the discussion of Self-Documentation, storing such information in the module itself — rather than in an outside document or database — decreases the likelihood of including wrong information, and in particular of forgetting to update the “Self-Documentation”, page 54. More details in “Indexing clauses”, page 890