Software Issues 4: The Demise of Reuse
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
For many years, reuse was one of the most talked-about topics in programming. Almost every conversation about coding touched on the benefits of reuse; every new initiative focused on reuse as a major consideration. The future of programming was seen to rely upon effective reuse. Everyone promised it. Few delivered.
Reuse died.
No one talks much about it anymore. If they do talk about it, it's often with disdain. Even highly experienced, talented developers scoff at the idea of reuse as something that sounds good but just isn't achievable in real life.
What caused the demise of reuse?
-
While everyone promised it, few actually delivered. Most code was not written using strategies that made it truly reusable. It lacked the flexibility, quality, and maintainability to be effectively reused.
-
Commercial components promised highly powerful reusability, and many people bought in. Unfortunately, many component companies went out of business, changed hands, broke compatibility, or for any number of reasons failed to deliver long-term reusability. The lack of availability of source code left many developers out to dry, and created a permanent taint on the idea of commercial reuse.
-
Finally, code can only get reused if developers know about it. A failure to create effective management and searching tools caused frustration as developers even in very small teams reinvented the wheel that someone else had already made available.
Even developers who truly understood how to reuse code—and took the time to produce code that could be reused effectively—found their efforts undermined by the rapidly changing technologies on which their code was based. They developed a reusable library; and then new languages, new DLLs, new operating system versions, new enhancements in built-in capabilities of the language, and any number of other external changes conspired to prevent their code from achieving a reuse return on investment.
For these and a host of other reasons, reuse is dead. People don't even bother to mention it much, as the word itself seems hollow and trite at this point. Many seasoned developers think you naïve for suggesting it. The concept has acquired the taint of naïveté.
This has to change. The concept of reuse must be resurrected, made a reality, and returned to respectability.
In the foreseeable future, software development will remain essentially an if-then-else process. It will remain limited by our very constrained language abilities. Increasing intelligence therefore means increasing the number of if-then-else statements we process. Given that reality, the only way to dramatically increase our capabilities and productivity is through reuse. Reuse effectively increases our high-level vocabulary so that we can reuse if-then-else logic without rewriting it every time we need it.
It is possible to develop code that can be reused effectively, and it is alive and well in isolated pockets of development. It only takes a little bit of planning and discipline. Let's deal with those reasons for its popular demise, in order:
-
The first reason that reuse died was failure to deliver. This was a reasonable response, since the code was not "reuse-quality." That means that it lacked the flexibility, standardization, and error-coding necessary to be reused effectively. If code cannot be adapted to one's needs, understood quickly, and relied upon to perform solidly, why would anyone reuse it? By following simple guidelines, it's possible to write code that's "reuse-quality." And if code is reuse-quality, why would anyone want to rewrite it?
-
The second reason was the shifting sands under reusable code that regularly toppled reusable code. However, just because code breaks when a new version of ADO is released, for example, that doesn't mean that it has no value. If the code was written to be truly reusable, it should have been reused extensively in one project—perhaps several projects within the same company. That reuse hopefully had substantial direct and indirect benefits. Also, even if those routines must be rewritten, that job is greatly simplified by having reusable routines to start with. Changes can be made in one place, without having to re-architect the strategy. Further, even if all the specific code must be rewritten, the knowledge of how to structure the job and handle the details can be reused.
-
The last reason for lack of reuse, lack of access, is also a problem that can be overcome by many simple strategies. The main method is simple communication among developers in a mutually supportive environment.
I personally have large amounts of code that are highly reusable and have returned a substantial, consistent return on investment over many years. For example, a well-thought-out, reusable library of DAO functions was reused and enhanced extensively for many years over many projects. That same library was updated for RDO, and then ADO with minimal changes. Many other developers have leveraged this code to write robust applications without having to relearn and recode all that experience.
Therefore, reuse is alive and well; if not in the hearts and minds of every developer, at least in isolated but vibrant gardens of reusability. It is still, more than ever, a practical, achievable goal that every developer should strive for. If you are writing reusable code, don't be ashamed to brag about it. If you aren't, don't scoff at the notion. Instead, ask yourself what you're doing wrong.
About the Author
Tyson Gill is the director of information technology at Alitum, Inc., in San Diego, California. He also teaches Visual Basic and Microsoft.Net programming at the University of California, San Diego. He is well known for his influential presentations on design, architecture, planning, and coding. Tyson is the author of Visual Basic 6: Error Coding and Layering (Prentice Hall, 2000, ISBN 0-13-017227-8) and the upcoming title Planning Smarter: Creating Blueprint-Quality Software Specifications (Prentice Hall, 2001).