Reuse
|
Reuse |
|
|
This article was written on December 1995 for the International Workshop on Systematic Reuse, held at the Peter Jost Enterprise Center, Byrom Street, Liverpool, UK on 8-9 January 1996. This paper was published in the workshop proceedings and it is also available in the Web from Reuse: A Cultural Change. A brief biography of the author can be found in Biography of Dario de Judicibus.
Dario de Judicibus
Doctor in Physics
The introduction of Software Reuse in a company is not just a matter of technological change, but of cultural and structural change. In fact, software development is not the only process affected by Reuse. Many other aspects of the life of a company have to be redefined to really take advantage of that discipline. Introduction of Software Reuse in a company is not a painless process. In fact, it requires significant changes to people evaluation, project planning, resource allocation. It may affect social relationships, productivity, quality, the company structure itself. For those reasons, most hindrances to such a re-engineering of a company are social and psychological.
Software Reuse, Human Factors, Reuse Process, Individual and Collective Syndromes
Use of the words he, his, or him in this document should be taken to meant he or she, his or her, him or her.
Reuse in not a new concept in industry. It is, for example, extensively used in the automobile, building, and furniture industry. In the computer world Reuse is the foundation of the hardware industry. However, its acceptance by the Software Development community is still very limited, and only the introduction of Object Oriented Technology (OOT) has given a significant impetus to Software Reuse in most software companies. Nevertheless, the potential advantages of Reuse are often limited by its tight link to OOT. In fact, Reuse is not considered as a valid approach to software development "as is", but just as one of the consequences of using object oriented programming. In many cases, people confuse Software Reuse with Object Oriented Technology, and stress too much the technological aspects of Reuse, rather than the procedural and structural ones.
In fact, Reuse is not a technology, a programming language or a development tool, as well as it cannot be reduced to simply assembling existing code. Reuse is a methodology, and implies the definition of a new process and programming discipline, which have significant consequences on the structure and the culture of a company.
This is at the same time the strongest and the weakest point of Reuse. Once we realize that Reuse is not just a new technology to acquire but a deep change in the way we should work, the return of investment could be really impressive. However, since such an understanding has to bring psychological and social difficulties to account, the diffusion of Reuse in the software community is really scanty.
There are two main problem areas to introduce Reuse in a company. The first one is due to structural problems, the second one is related to human factors. The latter is particularly critical, since overcoming psychological hindrances cannot be obtained by stating the advantages of Reuse from a strictly logical point of view. It is necessary to single out the cares of involved people, and help them to overcome those fears.
Once we get over individual human factors, we have to face the reengineering of company structures and processes. Such a reorganization may cause social problems due to collective human factors. Hereinafter there is a list of the most common individual and collective reactions to the introduction of reuse in a software company, and some recommendations to solve or limit those problems. However, note that most psychological problems have a well-grounded base on structural and procedural obstacles which often provides a pseudo-logical foundation to individual and collective resistance to Reuse. Therefore, human factors cannot be tackled independently of organization aspects.
Individual factors are those that involve the single employee, his fears, his worries, his weaknesses. They are particularly important when the person that is opposing the change is a key person. A manager, a key professional, a person that has to take decisions, and that, therefore, cannot be simply substituted because of his resistance. Those people are often worried that Reuse might limit their position in the company, or might represent a challenge that they cannot face. In most cases this is not true, and the approach to this reaction is to help them understand that the situation is really the opposite. That is, that Reuse will reinforce their position in the company and that it represents for them an opportunity to grow.
The most common individual syndromes are: the Artist's Syndrome, the Standards' Phobia, the Egghead's Syndrome, and the Feudal Lord's Syndrome.
Most developers consider themselves artists rather than workers. This is mostly due to the intrinsic characteristics of software development. In fact, designing and writing code requires both a good confidence with the technical aspects of programming, and a significant amount of fantasy and intuition. However, the apparent facility in writing code, and the fact that most developers have not a clear understanding of costs of writing lines of code, makes people in software production behave differently from hardware engineers.
For example, an electronic engineer who is designing a new video card for personal computers, does not redesign from scratch all the components of that board, but looks around to identify the best components that are available in the market, and provides the video card with added value by designing new circuits that have not been yet implemented by competitors. During this process he is always very aware of costs, and he does not plan the need for a custom chip unless really necessary. Even in that case, making a new chip is such an expensive approach, that he would prefer to change his design to take advantage of existing integrated circuits, rather than making new ones.
A software engineer often faces the problem to make a new piece of code by designing it from scratch. He automatically accepts the reuse provided by the builtin functions distributed with the compiler, or the class libraries that are included in a C++ package, but rarely does he take the initiative to search for functions or class libraries that are already available inside his company or on the market, and that could facilitate his work.
When a reusable piece of code does not match exactly the requirements of programmers, there is the habit to reimplement that piece of code rather than changing the application design to take advantage of existing software parts. A hardware engineer has no problem to slightly change the design of his card to take advantage of already existing chips, if necessary, because he knows the costs of making a new chip. A software engineer often prefers to sit at his terminal, and make that piece of code from scratch, rather than changing his design. Costs are the manager's business, not the programmer's.
How can we avoid this problem? There are three aspects to consider. The first is purely psychological, the second is cultural, and the third is structural.
First problem: programmers are worried that reusing parts may limit creativity, forcing them to be just assemblers of already existing code, rather than artists. This problem can be eliminated if we present Reuse as a way to take programming to a higher level of abstraction. We could remind programmers that when they moved from machine languages and Assembler to high level languages as FORTRAN, Pascal, or C, they did not give up the pleasure of programming, nor did they give up their creativity. They just stopped reimplementing wellknown algorithms to concentrate on a higher level, delegating to builtin functions the most common functionalities.
The concept of builtin operations became larger to include file I/O, string operations, printing, and so forth. Later on, several compilers provided their own extension to the standard libraries, including math libraries, 2D graphic functions, window interfaces, and so on. This introduces us to the second problem: dependencies and support.
The main reason for programmers to naturally accept reusable parts when they are shipped with their favourite compiler, but not from other sources, is that they had already accepted that product as a dependency, and they trust the support provided by the supplier. Convincing a developer to change compilers is not that easy. On the other hand, programmers do not rely on parts that are provided by various organizations or by other developers, even if in the same company, unless there is guaranteed support. And this takes us to the third problem: organization.
Most software companies are organized to associate each development group to a specific project, intended to make profit by developing a product for the market. A group that would develop reusable parts only for other development groups in the same company is considered a costonly unit, as well as research groups. There is still a culture in many companies that consider those costonly groups a luxury, not a necessity. So, when Reuse is introduced in a company, many managers try to push product development groups to produce parts, rather than creating Reusable Part Centres. But a development group tightly coupled to a product cannot provide the level of support and responsiveness that is required for reliable, reusable parts.
Therefore, the Artist's Syndrome is mostly a psychological problem, but it is based on the lack of appropriate modifications to the company processes and organization, which weakens the confidence of programmers in reusable parts.
Standards are the foundation of Reuse. Reuse implies that you can assemble parts that have been independently developed in different moments by different programmers. That may cause serious problems of interoperability. Standards are a necessary even if not sufficient condition to avoid sideeffects when assembling parts. In hardware, standards ensure that a video card developed by a company can be used inside a computer made by another company. They ensure that in most cases you can buy your computer's monitor independently from the computer brand you choose. Hardware standards are recognized such an important aspect of hardware production that imposing a standard to the market is a success for a company. Everybody in computer world has heard of IDE, ISA, PCI, VGA, PCMCIA, and so forth.
Software standards exist. They are often the result of the effort of large international communities or company foundations, or invented by a single company operating often in a very specific market. Names like CUA, TWAIN, CORBA, TrueType, OLE, PostScript, and so forth, are wellknown among programmers. However, standardization is often seen by many developers as a limitation to their creativity. Imposing standards in a company is difficult. You may ask developers to use certain naming conventions or to use a specific compiler, but many people will mumble if you ask them to use a specific programming style for writing code, or to follow welldefined rules when defining new classes. In fact, whatever standard you may define, somebody will stress the weak points that are always present in any product of the human brain. It is difficult to make people understand that an imperfect standard is better than no standard since developing software is not a technological problem, but an industrial one.
This phobia should be fought by planning a companywide campaign to advertise the necessity and the advantages of standards. It is necessary to motivate managers to push company standards in their groups, to motivate developers to use them, and to set up an education plan to disseminate the usage of standards among programmers. The availability of tools and products which help programmers to write code that conforms to the company standards will further facilitate their diffusion among programmers.
For many people, knowledge is power. To be an expert is a position to safeguard. Many experts do not like to share their skill with others because they are worried that sharing skills may reduce their importance in the company. Reuse is based on skill sharing and skill encapsulation. Sharing, because Reuse requires artefacts to be made independent of specific people to become a company property. Encapsulation, because properly made reusable parts can encapsulate solutions that are obtained by an expensive and time consuming analysis, so that these parts are available also to nonexperts through an easytouse interface.
Most eggheads are freelance, wild geese, people who do not like to work with others. The Egghead's Syndrome can be fought by creating a teamwork mentality in the company, by awarding those who share their skill and help others to grow. This problem can be drastically limited by introducing tutoring and mentoring in the company. That would also help to make newcomers feel at ease in the company, increasing the harmony and enthusiasm in each group.
Many managers and team leaders think that their importance in the company is measured by the number of people and projects they manage, by the budget that they received, and in general by the resources with which they have been entrusted. Reuse allows a simplified organization, where large projects are carried out by smaller numbers of people, with significant saving in costs, time, and resources. So Reuse is sometimes seen as a potential danger to the personal career of managers and professionals.
Furthermore, Reuse creates dependencies on other development groups, and in general a good integration of each group in the company mechanisms. That is seen as an interference in the manager's area of control, too.
Even in this case the answer is pushing teamwork culture in the company. Furthermore it is necessary to clearly uncouple the employee position from the amount of resources that he manages. Vice versa, company should award those people who obtain significant results with a few resources.
Collective factors are those which belong to the company culture, which is often partly originated by the social structure of the country were the company operates. For example, the "Not Invented Here" Syndrome is mostly unknown in Japan. Other syndromes are the "Technology" Syndrome and the "Revenue" Mania.
Some companies create in employees a culture of undervaluation of what is done by competitors. What a competitor does is "surely" inferior to what we do. We can do better. We do it better. Many employees do not even know the competitor's products. They are not motivated to use them, or at least to give a look at other products.
Such a culture rejects the possibility to reuse whatever was invented by other companies. People reinvent the wheel only to demonstrate that their wheels are better than the others'. This is done even when no license or royalty is requested to take advantage of somebody else's ideas.
This approach is often so deeprooted that people become distrustful at what is produced by other people in the same company. An internal competition arises with the consequence of a useless duplication of efforts rather than a better production quality. At the moment, in fact, most of the efforts are intended to demonstrate that what is done by others is worse, rather than what is done by us is better.
This syndrome can be cured by introducing in the company a Culture of Respect. Respect for competitors, respect for the professionalism of colleagues, respect for each other. Managers should invite their programmers to Vitality Sessions where competitors' products are shown and discussed. The objective must be to identify the weak and strong points of company's product with respect competitors', and to identify which actions could be taken to improve our own product.
When a new methodology, process, or technology is introduced for the first time in a company, it may not deliver its expected advantages immediately. It takes time to tune a new process.
So, especially at the beginning, the process itself is considered responsible for failures. The first OO project resulted to be more expensive than an equivalent "classical" project? Well, it is obvious that OOT is not such a good technology as advertised. A program based on class libraries is more difficult to maintain than good old procedural code? It is technology's fault! Very few people would accept the fact that most of the initial failures are due to themselves, that is, are due to the fact that the used process is still a hybrid of old and new ideas. For example, object oriented languages used as "advanced" procedural languages, classes based on procedural design rather than object oriented analysis, reusable parts that are badly documented, or that do not conform to the same standards.
A new technology might require deep changes in the way we work. A new methodology like Reuse can require deep changes in the way we think, too. To avoid that, it is necessary to carefully select a number of pilot projects led by people who are very flexible and aware that the first attempt to reuse code cannot deliver the results that Software Reuse promises in the long term. Those projects should give the possibility to simultaneously measure and tune the new process, and to demonstrate that reuse is possible. It is also necessary to create a culture that looks at technologies as just tools, which cannot be responsible for human errors, and therefore used as scapegoats when something goes wrong.
Companies tend to classify their departments as revenue makers or costonly departments. For example, a research department is often considered a costonly department. When a company has financial problems, costonly departments become natural candidates for cuts. In some companies this approach is so dominant, that when a department requests a service from another one, it is debited as a cost (internal money).
Software Reuse tends to differentiate development groups as Reusable Part producers, and Application builders. The reason is that a development group that produces reusable parts cannot be tightly coupled to a specific product, because it would be heavily influenced by the perspective of that product. So, Reusable Part Development Centres are intrinsically costonly departments.
Many managers are hesitant to create a larger number of costonly departments than those which are considered revenue departments. That is caused by a mentality that is not able to see the company as a whole. They look at the company background as a bunch of independent units which, in the best of cases, are requested to cooperate. This approach is strengthened by the Feudal Lord's Syndrome. Often the company becomes an abstract concept, and each single department is individually evaluated, for what it provides in terms of immediate revenue, rather than for the contribution to the company revenue. The larger the company, the stronger is this mindset.
The solution is to make each employee feel as a member of the company, rather than of a specific department or group. The company organization should be seen simply as a necessary decomposition of the whole to better manage the structure. An organization that can also continuously change, according to the change of the external world. In addition, it is necessary to set up a metric to provide a measurable evaluation of costonly departments in terms of equivalent revenue, so that their contribution to the company can be clearly understood by everybody, and so that they do not become natural candidates for cuts when the company has financial problems.
Any major change to the way people work in a company involves psychological barriers, at individual and collective levels. Those barriers must not be underestimated, because the success of a company to change depends on how much its employees trust the change. Furthermore, none of those psychological barriers is a personal problem only. Most of them have a solid foundation in company structure. This should be addressed to diminish resistance to change.
The introduction of Reuse in a software company is a major change. That cannot be painless, and requires a significant effort by many people. Reuse is by definition a teamwork based approach to development, based on cooperation and a good functioning of company logistics. Just as a worker in any industry cannot have good productivity if the machine maintenance is poor, a product development group cannot have good productivity if the importance of their support services is underestimated.
Reuse divides software development into two areas: part producers and part consumers. Part producers are no longer a production unit, but a logistic one. This has a profound impact on company culture. If human factors are not considered or are underestimated in this cultural and structural change, software reuse will remain an unreachable objective for the company.
I would like to acknowledge the terrific support that all the members of the IBM Reuse Technology Support Center gave to me in the last few years. In particular, I would like to thank Rock Angier, Peter Drescher, Ian Glass, Hal Gregorius, Bob Heine, Dave Livesey, Slavko Malesevic, Ev Merritt, Jeff Poulin, Norm Rudikoff, Sam V Sultana, Jesus R.Tirso, Thomas Wappler, and Kathy Yglesias. It was really a pleasure to work with them. A special thank to Giampaolo Soleri for his management support, and to Gil Arnold and Marjan Sarshar for help in improving the present paper.
Chosen for you
The Reuse Homepage - Useful information on Reuse
BCS Reuse Special Interest Group - Reuse know-how