When people first hear the term “reuse environment,” they tend to think of code reuse. In fact, that is usually the logical place to start. We’re used to developing applications using component libraries. Code reuse was also accomplished years ago through the use of subroutines. However, reusing code is only part of the reuse culture. Reuse can come into play during many parts of the development life cycle.
There are two basic aspects of the reuse culture. First, in almost every activity you do, you start by determining whether there may be something already available that you can use. If you can’t use it entirely, it still may serve as a starting point. Second, for every piece of work that you create from scratch (and there will still be a lot), always ask yourself whether someone else may be able to reuse it later.
Let’s consider each phase of a project from a reuse perspective.
Don’t miss our previous articles on the development of a reuse environment
- “The reuse environment is more about culture than technology”
- “Laying the groundwork for a reuse environment”
- “Building a reuse environment: Recognize the benefits and overcome the barriers”
- “You need sound processes and training to facilitate reuse”
- “A successful reuse environment requires new roles and incentives”
- “Capture the value of your reuse environment”
Always start with one basic question: Has this problem been solved before? If it hasn’t, ask whether something similar has been solved before. You may discover a starting point to save time and effort going forward.
I once worked for a large company that had at least three distinct manufacturing packages. Could one package have worked for all three sets of needs? Perhaps, but no one was asking the reuse question back then.
When the project is being planned, look for anything that can be reused. This includes the project definition document, workplans from similar projects, work estimates, and project management procedures.
During the analysis phase, see whether you can reuse requirements from a similar project. You should also check for requirements for different solutions from the same department. Looking further ahead, determine whether design and code components exist for common sets of requirements. If a component exists that may represent 80 percent of the business need, you can also ask whether the business process itself can or should be modified to reflect the component logic.
In the design phase, see whether you can reuse any design models for your application. You can often reuse online process definitions, screen layouts, report designs, and technical architectures from other successful projects, even if the solution itself is different. For example, many of you know the difficulty in designing an application that needs to exist behind a firewall (or multiple firewalls). If a second, unrelated application also needed to exist behind the firewall, I’m sure that you would recommend that its developers adopt your design and your techniques rather than build another infrastructure from scratch. Also look for opportunities to reuse testing plans, testing scripts, etc.
Most developers probably start their reuse search during the coding phase. If you were able to reuse elements of other people’s analysis and design, chances are there are reusable business logic code components you can use as well.Even if you couldn’t identify any reuse opportunities up to this point, now’s the time to search the reuse library to see what is there that could save you time and effort. There are always opportunities to reuse vendor class libraries and functions. However, the biggest value comes from reusing business process logic.
If you use prebuilt components, you should not have to independently unit-test them. You should be able to hook them in directly during the integration test. Testing scripts are usually tedious to create and implement. Look for every opportunity to reuse previous examples as your starting point.
Reuse is more than just reusing program code. It plays a role in almost every phase of the development life cycle. Launch your project by asking one simple question: Has this problem been solved before? Then, look for reuse opportunities as you plan, analyze, design, code, and test your work.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.
What do you reuse?
We have said several times that reuse means reusing more than program code. What types of things have you reused to make your life easier? Has shop formalized the process? Send us an e-mail with your ideas and suggestions or post a comment below.