Component-Based Development
Why Hasn't the Vision Met Reality?

Wednesday, February 20, 2003
By David Tanacea, President of TopCoder Software

For years now, we in the software development industry have been extolling the virtues of component-based development (CBD). The benefits of object-oriented design and component-based development seem obvious:

• Reusing software saves money in the development phase of software projects, i.e., the more components you reuse, the less software you have to build.
• The more applications in which you use a given component, the more valuable that component becomes.
• Reusable components enable application developers to customize applications without high costs and long development cycles.

Reused software components have fewer bugs because they are used more often, and errors are uncovered and corrected along the way.

If CBD is easier to maintain, cost-efficient (saves up to half of software development costs) and incorporates a shorter development cycle, why then aren't software components utilized in more applications?

The answer lies in the application development process, especially the beginning stages of software development—research and discovery. Put simply, CBD has been hampered due to lack of discipline and lack of expertise, especially when applying CBD methodology to the application development process. Software applications need to be well defined before coding begins.

Iterative prototypes, functional requirements, business process flows and transitions, and use cases are all critical tools used in application design. However, in most instances, the issue isn't the tools that are utilized, but the extent to which they are used. In too many cases, coding begins after high-level use cases have been defined, which causes the problem. In order to realize the true benefits of reuse, use cases must be driven down to the lowest level of granularity before class diagrams are created. Then, component diagrams must be created and broken down to their lowest level to identify reuse throughout the application. When done well, the immediate results are low-level base components that are the building blocks of all software.

It is relatively easy to extend, customize and assemble base components into complex components. However, if base components aren't identified in the application design process, the application suffers from blocks of software that are unwieldy and improperly interfaced. Base components, because of their low level of granularity, are easier to utilize in multiple applications, thereby driving down the development costs of the organization as a whole, without forgoing quality and customization.

The second driving factor behind CBD's slow adoption is that proper application development isn't done rigorously. First, it takes knowledge and foresight to break down an application design to its lowest level. Second, there is always the urge to quickly finish designing and start coding!

Project deadlines approach like the proverbial freight train, and the paradox is, the extra time spent in the design process makes the development process proceed exponentially faster and with fewer errors. While this is true for any design methodology, it's especially true for CBD, as the benefits gained by a particular application are also realized by all additional applications that utilize that component.

There are several ways that an application developer can drive down the cost of applications and increase their quality. The most obvious is to enforce good CBD principles. Design and development should be separate, with different individuals working on each. Both must have their own peer testing and review process. Managers must ensure that the internal component assets are well organized. Developers must be able to easily search for components that meet their functional and technical requirements. Components must also be well developed and well documented. It's better to forgo the opportunity to reuse a component than to poorly build an ostensibly reusable component. High quality, low-cost commercial components should be utilized to speed the building of a company's reusable assets.

Finally, it is critical for all development benefits to be measured. Metrics that measure component cost (in component development and re-use), productivity (speed of development) and quality (number of defects) must be established and tracked. Application metrics, the number of places components are used, the cost per application (total cost divided by the number of applications) and the percentage of applications using reusable components (productivity increase) must also be established. Only through quantitative analysis can a process be continually improved. The results will make the benefits obvious, saving both IT and the organization's resources, and making the discipline of application development much easier to enforce.

By David Tanacea

Would you like to write a feature?