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

Computerworld - 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.

	David Tanacea is president of TopCoder Software. With more than 20 years of experience, he has spoken at a wide range of technology events, and frequently writes for publications and online outlets. You can reach him at www.topcodersoftware.com

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