A good idea lives or dies not only on the basis of its merit, but also by several factors that surround it. By calling this article "Politics of Reuse," we mean to examine the possibility of reusing billing and network management software in the creative culture of programming and the business environment in which programming is performed. The productivity gains promised by reusing software are not yet manifest. Executives want to reuse software so they can be competitive; they tend to think that reuse is a matter of discipline in the programming ranks. Although engineers have always been fond of standardized parts, they know that reuse without a sound theory and control leads to disaster. Everyone is willing, but the application and rewards remain stubbornly elusive. Imagine a situation in which you reuse a billing subsystem that propagates a poor algorithm.
Many trends, however, suggest that reuse will be common by turn of the century, even though massive reuse of software modules is difficult today. That confidence is supported by SRI International's Business Intelligence Program report 833, "Streamlining Software Development, Driving down the high cost of information systems through component-based software development," which projects the mathematical models to be in place by the year 2000. Today, successes with reuse suggest that some projects are getting shorter development intervals at lower cost. Projects that use UNIX and its C libraries achieve 20 percent reuse without extra effort. The goal is to reuse software modules as though they were interchangeable parts of hardware.
One big stumbling block is that revising software is very difficult without the originator's help because most code is obscure. Designers must work hard to get the organization of logic right at every level. It is even harder with object-oriented code because the long-reaching effects of early decisions in bottom-up design demand greater insight than in top-down design. Managers don't tout their product' internal clarity. Efficiency, features and production schedule--all come in for praise, but clarity--never! Yet only clear code can be modified. Preserving clarity through modification cycles is even harder. During Norman Wilson's five-year tenure as the primary maintainer of research UNIX, he wrote a negative amount of code. The system became more capable, more maintainable, and more portable. Imagine a major network management project in which code is subtracted while a feature is added! Allocating as much as 20 percent of the effort on a new release to improving the maintenance of the system pays large dividends by making the system perform better, avoiding failures caused by undesired interactions between modules and reducing the time and space constraints on design of new features. The goal is to reduce the amount of processor time that old modules use and the amount of memory they occupy or I/O they trigger but hold their interfaces fixed. To provide new features, other modules can be modified or new ones can be added. This strategy naturally leads to reuse within the system. The greatest economic benefit is to reuse software at the application level. Once 80-percent reuse is achieved, a four-fold increase in productivity is projected. For example, Cuppertino, Ca.-based Portal Software Inc., provides a set of billing components that can be reused in network management systems to bill for Internet services. Portal designers had the foresight to keep the interfaces clear and simple and limit the size of their object libraries. Commercial off-the-shelf components such as these can let the network management industry stay at the forefront of software-technology application.
Qualified Success
Using network management platforms has resulted in significant reuse of software. After widespread use of platforms, 50-percent reuse became common by 1995. In 1985, reuse was the exception.
With all this success, why the frustration? First, the financial payoff for reuse comes only after a module is used three times. The investment in making modules reusable increases the cost of the first product. Second, today's software development processes are defective because they treat everything as new development. There is no recognition of, or funding for module owners in one application area to maintain modules for developers in other areas. The "you use it, you own it" philosophy implicit in most software groups renders a self-sustaining culture of reuse impossible. An example close to home is my son, who reused a string package to track his school library's "overdue notices." The index scheme needed to be changed. After two weeks of failure, he let the package compute its own worthless index and added a postprocessor to compute the proper index. Although this processor added performance overhead of 20 percent, the module could not be modified reliably, and the module owner was nowhere to be found. The library used the system cheerfully for years; the system consumed more computer resources than was strictly necessary. When it was expanded to another library, my son was long graduated, so the administrators wisely decided not to tinker. Anyone who ever comes across a "Glenwood Library Overdue Notice" from someplace other than the Glenwood School, will know that reuse constraints prevented a name change. The lesson learned is that when you reuse a module, do not modify it. Get the module owner to make it more general, live with it as is, or develop it from scratch.
Conditions Fostering Reuse
The literature, IBM's experience and our work shows that it takes 1.5 to 2.2 times the effort to write a software module so that it is a reusable asset. The following criteria must be met:
1. Standard interfaces to the operating system must exist and be followed. For example, kernel changes to UNIX are unacceptable. They reduce flexibility in handling new communication protocols.
2. Standard approaches to module interfaces must apply universally. Abstract mechanisms, such as self-describing tag-value interface design, can penalize performance.
3. Application generators need to produce about 25 percent of the product, especially for user interfaces.
In his article, "Hackers in a Decade of Limits," published in the January 1994 issue of American Programmer, Roger Pressman points out that wizards such as Ken Thompson of UNIX fame can whip out thousands of lines of defect-free, crystalline code in a few weeks. He goes on to caution that these developers make up less than one percent of the programming population. The rest need to follow formal processes, which presume a software theory of design constraints to ensure stable dynamic behavior of modules. This theory has yet to be articulated though some experts believe that a software system can be modeled by the growth equation of chaos theory. If this conjecture is accurate, exhaustive regression testing would no longer be mandatory to assure reliable operation for all software changes. The chaos theory growth equation may be a predictive model for the long-term behavior of a software system. Software developers know that their systems act strangely, including crashing or hanging, when users observe small differences in operation due to new input data, execution of code in new sequences or exhaustion of computer resource such as buffer space, memory, hash function overflow space or processor time. When even the smallest segment of new code has been added to a system, experienced software managers retest and re-verify system operation through an exhaustive set of regression and new functional tests. When existing software is being changed, this re-testing hurts productivity.
The owner of a reusable module faces the formidable task of having to know all its users' needs. For example, take "diff" in UNIX. This may be the most reused module on earth. Not many developers understand how it works and fewer still try to change it. It is an example of significant reuse.
Reusing Modules As Is
Data collected on the reuse of 2,954 modules of NASA programs clearly illustrates the shocking conclusion that to reap the benefits of the extra original effort to make a module reusable, it must be reused essentially unchanged. No change costs five percent; the slightest change drives the cost up to 60 percent. The issues of who pays the differential and who pays for ongoing support remain serious barriers to reuse. Within an organization, however, success is possible.
For currently intractable problems, systematically reusing software across application domains has been impossible. There is ongoing work in modeling application domains to capture the relationship between requirements and object types so that selecting these features can allow software architectures to be reused. Also, reuse even in the same application domain is successful only when throughput and response time are not overriding concerns. Finally, maintaining an asset base of software modules is not yet possible unless modules are in packaged libraries and are utility functions.
Where reuse is successful, mangers pay much attention to detail and are willing to invest in design for reusability. Software configuration management assumes an existing base of software components from which the components of a specific system are chosen, assembled, tested and distributed to a user. Even then, exhaustive re-testing is still required to root out "undesired interactions."
Perspective
The network management software industry has already committed a major investment to allow components to be reused. Object-oriented programming and large-scale reuse offer the most promising near-term breakthroughs, and successful companies are embracing them. Customers know about object-oriented programming; their demand for it gives a competitive edge to the projects using it. The trick is to bind our investment with attentive managers who are willing to invest in reuse.
Advancing new technology is a tricky business. When a library of reusable modules exists, shifting to new technology is difficult. Professor Ed Richter of the University of Southern California points out that the more technologically competent an organization, the more difficulty it has adopting new technology. If an organization has developers who are good enough to design reusable modules in the first place, can it turn its back on those modules to embrace new technology when the time is right?
We should proceed to apply the degree of reuse that we understand. We should pursue the mathematical theory that will make the redesign of modules a stable process. We should understand that designing modules of reuse is not the only element in moving software production to an industrial base from its current cottage fabrication. Those who doubt that we are still a cottage industry, should count the number of network management software companies that have not advanced to a SEI CMM level of 3. Have any of these companies attained a rating of 5? There is considerable risk in being on the leading edge, but vast rewards come to those who meet the challenge.
Lawrence Bernstein is a recognized expert in network management, software and technology conversion. He is president of the National Software Council and is a consultant through his firm Have Laptop Will Travel. Larry is the chief technology officer for Telecommunications Intellectual Software, which builds software systems for managing telephone services. He can be reached at lbernstein@worldnet.att.net.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article