(N is the number of times the component is used, IT is the integration time for using the component, RBE is the Reuse Build Effort, and BE is the Build Effort.).

It is important to remember the time required to build a reusable component is much longer than the time required for building it for an application. For example, if I were to build a library to evaluate and parse mathematical expressions on the fly for .NET into an application, it would take me 30 hours. However building the same logic as a component, in the worst-case scenario, would take two and half times as long (75 hours), including peer review, design, and development. Imagine if I used that same logic in 10 applications. The equation would evaluate to the following:

((10 * 6) + 75 = 135) < 10*30 = 300)

(Note: IT in this case is 20 percent of the build effort (30 *.2 = 6).) Even if a company is not currently participating in a reuse initiative today, most developers informally share code, snippets, and classes. The best developers maintain their own library of useful utilities and algorithms under their desks and are sharing these code snippets with other colleagues. Although this informal reuse and sharing program does not cost the company anything, it has several hidden costs.

Let's revisit the earlier scenario with a formalized component versus informally shared code. The two biggest differences between the two are in the documentation and testing of the component. Without the rigor of a peer review process and requirements to become a formalized component, the integration time to use the component will be significant. To truly measure reuse, you must take into account the amount of time it takes to become familiar with and understand the component. The integration time stated in the previous example will dramatically increase as the documentation, consistency of deliverables, and support structure vary between homegrown components. Furthermore, the most successful reuse programs utilize an asset repository structure. A missing factor in the previous equation is the effort to retrieve not just any component, but to find the exact component the developer needs to utilize. Component identification time for the exact component must be added into the equation as well. If the component is misclassified or the description is incorrect, the identification time will increase. Furthermore, informal reuse program identification times are significant since no central repositories or search methods exist other than word of mouth. If we add component identification time into the equation, the equation for each distinct user is changed to the following:

(n * (CI + IT)) +RBE < n * BE
(CI = Component Identification)

As the component is reused more and more by the same user, the component identification time will grow closer to zero.

Another missing factor from the above equation is the code maintenance time. Maintenance can be defined as bug fixes and enhancements to a piece of logic. An interesting study by Pastoo Mohaghedghi and co-researchers analyzed code reuse programs for Ericsson Norway (www.idi.ntnu.no/grupper/su/publ/phd/ mohagheghi-thesis-10jul04-final.pdf).

One of the more interesting conclusions drawn from the study is that bugs and changes are significantly reduced in reusable components. Research determined that reusable components were far more stable than nonreusable components. If we were to add maintenance costs into the equation we have been building, the equation would look like the following:

(n * (CI + IT)) +RBE + MT < (n * (BE + MT))
(MT = maintenance time)

If the component is not reusable, maintenance time must be added into the total time to create the component and multiplied by the number of times the functionality was written. Assuming a worst-case scenario that maintenance time is equal for both reusable components and duplicating the logic in each instance, it is still beneficial to use reusable components. Figure 1 illustrates that as the number of times the component is used increases, the number of development hours saved becomes more significant.

The last factor missing from the equation is the definition of hours. Hours to complete a given task is an arbitrary measurement and difficult to quantify. The total number of hours will vary based on the developer's knowledge of the subject area and their skill level. Furthermore, not only will the number of hours vary but so too will the hourly cost based on the skill level of the developer. It is extremely difficult to identify the best design and development talent. Once a company has identified their best programmers, they should be working on strategic applications that give the company a competitive advantage. In addition, junior developers must be deployed on nonmission-critical applications. An objective rating system is required for proper allocation of existing resources and to thereby maximize productivity. Once a company has accurately assessed and assigned internal resources, it is hard to build reusable components due to application timeline constraints as well as the additional effort to properly design the reusable assets. Therefore, companies should look to third parties for their generic components. These external sources can spread the cost of using top-notch programmers across their entire enterprise.

In order to take advantage of reusable components, IT departments will have a higher success rate if they actually attempt full Component Based Software Engineering (CBSE). Without dissecting an application into granular functionality it is extremely difficult to identify the reusable components to use in the application. In the following example, we will walk through a use case, activity diagram, and sequence diagram that reduce a problem into fine-grained functionality. Next we'll map it to reusable components and combine the components by using the .NET framework to reach the end functionality.

• Figure 5