From the Trenches
Directions / Commentary
Reuse, Recycle
Code reuse is a subject near and dear to many a programmer’s heart. It seems the subject means even more to managers, because increased reuse should mean less development time and thus, a lower overall cost to produce the software. Why then, is it so difficult to find successful stories of code reuse? To answer this question, let’s look at a typical software company.
How many string utility functions do you think exist at your company? Put another way, how many string utility “wheels” have been reinvented at your company alone? How many have been reinvented throughout the world? Do you think every one of those are identical? You might even argue that one particular implementation is the fastest, while another is more flexible, and yet another addresses needs specific to your company. Why shouldn’t there be one set of reusable code to address these issues?
In the Delphi market, VCL components contribute extensively to code reuse. Look at any third-party Delphi Web page for confirmation. ActiveX controls, COM and CORBA objects, JavaBeans and Design Patterns all contribute to the potential success of code reuse as well. However, some purists may argue that this isn’t code reuse because you’re not really reusing source code, but rather, reusing compiled code. Fine, let them debate that semantic point. Meanwhile, I’ll be developing systems using methods, techniques, and libraries that have been written and debugged over time. Perhaps I’ll coin a new buzz-word by using the phrase “component reuse” to more accurately portray what all of us Delphi developers already know. Component reuse works, and it shows in our schedules.
The whole purpose of reusing code is to allow you to not worry about the implementation details of how to write the code from scratch. Therefore, by definition, there is some higher level of abstraction shielding you from these implementation details. This is what affords increased productivity when employing component reuse strategies. It lets you focus on the big picture of getting one component (i.e. library) talking to another, as opposed to fretting over the details associated with creating this component. Why then, would anyone care whether we are actually linking an OBJ file into our EXE, or that we create a DLL or OCX to encapsulate our business logic? As long as the component can be reused, it’s a success.
Finally, let’s address what it will take to make component reuse a reality in a programming shop. There are two groups that are affected: programmers and management.
Programmers need to change their attitudes, behaviors, and years of habit to focus on how they can help the company through component reuse. A programmer:
• must first ask this question before coding a new library: “Has this already been written, and if so, can I integrate the existing library more easily than writing it from scratch?”
• can no longer think: “I’ll just code it this way and clean up the code after the release.”
• must constantly think in global terms. After every set of functions, a programmer should think: “Can someone else use this library, and if so, what can I do to make it easier to reuse?”
• should no longer look at their code as their code. It’s “public domain” to the company.
Managers typically want to see progress yesterday. Instant gratification is fine, but just as in life, seldom does that translate into long-term happiness. Managers:
• must accept design as necessary to software development. This is true for all projects, but it is even more important if you want to try and leverage your code through component reuse.
• should plan for reuse. This can be as simple as encouraging developers to take on the mind-set of component reuse.
• should establish in-house peer review of code to help identify candidates for reuse.
• should have a “toolsmith” to ensure the consistency of the code being checked into the common library.
Software development companies should do everything they can to promote component reuse. Companies who take full advantage of component reuse could find themselves with a team of programmers whose job is to make the tool set easy enough for any new programmer to be productive immediately. Another benefit is that the group of component developers can bridge many departments, helping each become more effective with their software development efforts.
Employing component reuse strategies at your company is a major change, but the efforts and eventual successes that follow will pay for the increased planning.
Dan Miser is a Design Architect for Stratagem, a consulting company in Milwaukee. He has been a Borland Certified Client/Server Developer since 1996, and is a frequent contributor to Delphi Informant. You can contact him at http://www.execpc.com/~dmiser.
Mr Miser asks the question “Why is it so difficult to find successful stories of code reuse?” He proceeds to discuss how and why companies can promote component reuse.
Mr Miser discusses component reuse.