Issues Affecting Code Reusability

So if reuse is such a good thing, why not apply it to computer programs? Well, the good news is that you can. Reuse has been around for years. The bad news is that not many companies take advantage of it. Tight schedules, the changing nature of technology, and the difficulty of putting together a top-notch development team all account for the lack of reuse.

Deadline Pressures

Many projects come under pressure when schedules start to slip. When the pressure reaches a certain point, good design, coding practices, and coding standards are often forgotten in a mad panic to deliver. Designing and writing reusable modules and applications takes discipline and the enforcement of consistent standards; unfortunately, these practices are usually the first casualties when a project threatens to overshoot deadlines. (See Chapter 15 for more about how to manage projects successfully in today's competitive and hectic development environment.)

Knowledge of Current Technologies

To develop good reusable code, you must know first what you're trying to achieve through reuse and second how to achieve your goal with the tools you're using. Computer programming languages have come a long way since the early days and most now support the creation of reusable components to some degree. Technology—especially object technologies such as ActiveX and COM—has also improved. Keeping up with the ever-increasing number of languages and technologies can be hard work, and many organizations are tempted to stick with what they know. Although this conservative approach doesn't prevent the development of reusable solutions, it does mean that opportunities to develop more effectively are missed.

Quality of Development Teams

The quality of the development team plays a big part in the process of developing for reuse. The project manager must understand the technology and the business in order to set priorities and to justify the effort required to build high-level and reusable business components. Many companies employ project managers who are not technical. This practice is based on the business theory that a manager should be able to apply the same management techniques to any type of project to achieve the same results. The Mandelbrot Set (International) Limited (TMS) has a policy of assigning project managers who are also good coders. The benefit of a technical project manager is that he or she is acutely aware of problems that can occur and is able to counter them. The project manager can also carry out design and code reviews to ensure that the design is realistic and the code follows the design. This ability is extremely important if external contractors whose work standards are unknown are hired to work on the project.

Analysts and designers also need to be aware of the technology to ensure that the application's design is realistic and achievable in the scheduled time. Often the application design is incomplete when development starts. An incomplete design will almost certainly result in costly redevelopment of certain components. In the worst case, redesign might not be possible because of time or other constraints. If a reusable component is not correctly designed and built, any future development dependent on that component will suffer because of the effort required rectifying the original flaws. A future development team will probably just write its own version of the component.

The programmers have the important job of building the application to specification. Their task will be harder if the specifications and design are not complete or correct. Programmers should also ensure that the infrastructure code is reusable. It is here, in the program's infrastructure, that reusability can have a major impact, not through the reuse of business components but through the reuse of common code—that is, code that can be used by other programmers on the same application or in other development projects. Good communication is needed among programmers so that they all are aware of what code is available. The programmers also need to be sure that any code designed for reuse is well documented so that other team members know exactly how to use a particular unit of code. How many times have you written a particular function, only to discover that it already existed? Or tried to use an existing function but ended up writing your own version because you couldn't figure out the correct parameters for the existing function?