"The amount of man effort the component displaces, as a function of both volume of code, knowledge required and complexity"

"...and let nothing detract from the value proposition"

Just like the commercial component authors we've just looked at, achieving a high level of reuse for the components that we write is probably an objective for most of the people reading this article. Whether that's for commercial gain or internal cost saving really makes no difference, it's all about deploying components rather than writing code. Unfortunately, many people starting out in CBD often believe that just because they wrap their code in COM or JAVA interfaces they are going to get reuse and start saving (or making) money. In reality this is not the case and to find out why, we first need to look at how and why the consumers decide to reuse a component rather than build a function for themselves.

Until the advent of the software component, 99% of applications were realized through teams of programmers writing code by hand. In this model any given facility of the application has as a development cost attached to it. That cost is a function of the number of man-days that it takes to design, code and test, multiplied by the cost of those days. The primary reason for deploying a software component instead of writing it by hand is that it delivers the same functionality for a fraction of the development cost. If the cost of deploying the component across your development team and the live environment is greater (or even similar to) the cost of developing it in-house then there is simply no reason for you to go down the component route.

Whilst the value proposition of software components is easy to understand, the act of deploying prewritten code instead of writing it by hand is a revolutionary step. Deeply ingrained cultures have grown up around the "art" of software development, and people's egos and reputations are attached to the act of delivering applications successfully. These attachments lead to an inappropriate bias when it comes to making the "Reuse or build" judgment. Designers and developers alike become overly optimistic in their ability to deliver any given functionality and suffer tunnel vision when trying to evaluate the breadth of work to be undertaken. Often when components are evaluated, any discrepancies, no matter how small, between the apparent capabilities of the component and the needs of the customer requirement become exaggerated beyond reason and any failure of the component to communicate its true abilities and method of use will lead to its instant dismissal.

To overcome these hurdles you need to implement a two-pronged attack. On one side, you must build components whose value proposition is clear. That is, the amount of man effort the component displaces, as a function of both volume of code, knowledge required and complexity, must be high in relation to the cost of deployment. Representing intensely complex subject areas (like the complex UI work in grid components or specialized encryption knowledge) can instantly dismiss the desire to create the functionality in house. Similarly, wrapping up years of man effort in a single component can also make the reuse decision a no-brainer, but it is worth noting that this is a much harder proposition to represent because of the developer's tendency to underestimate the time needed to develop any given piece of work.

On the other side, you must ensure that no snags will detract from the value proposition created by the component. This means keeping the functionality complete but concise, and communicating the purpose and method of the component with utter clarity.

If you can successfully execute this attack then your components will start out in life with every chance of being reused many times over.