Nightmare of component based development (3)

With component based development comes parallel development. Different components are developed simultaneously, and different product integrations may be performed simultaneously. This leads to the problem to determine which development activity has the highest priority. One product development (or integration) may be higher priority than another, but the technology roadmap of a component may have a long-term impact on product developments to come and thus requires a higher priority.

So even though component based development is a way to achieve efficient development, priorities may be conflicting even beyond the scope of authority of the responsible managers. In principle, the upper manager should decide, but he may have insufficient insight in the all the relevant factors. In my experience, marketing usually dominates technology and thus short-term gains dominate long-term losses.

To protect the value of technology roadmaps, many organizations adopt the concept of ownership. In my opinion, this is an artificial solution as it gives more or less unconditional priority and authority to a single department, which places a rational decision on a political agenda. One of the counter-effects is that the owner of a component does not allow anyone else to modify the component, or even access the internals (source code) of the component.

This introduces another undesirable effect, on configuration management. The owner of a component claims proprietary ownership of the component and thus any change must be performed by or authorized by the owner. But if different product developments run in parallel, product-specific changes to a component (or prototyped changes) are delayed because of limited resources (and thus prioritizing of activities) require the owner to make choices. So, the "product developers" will ask for a preliminary copy of the component to make their own changes, put those changes in the product and only if they prove that the change is viable (i.e. the customer is satisfied with it), they submit a change request at the component owner.

But since the component owner has limited resources, the (prototyped) change is likely to be "reused" and taken over almost entirely without much re-engineering to comply with the architecture. Even worse, the prototyped change may have been developered in a non-standard CM system using non-standard processes (e.g. a quick & dirty implementation). Thus, the perception grows that the standard processes are very inefficient (late results). And since the component owner does not allow "hacking" into his CM system (which increases the risk for instability of the entire code base), the perception is grown that the CM system does not support parallel development in a safe way.

In other words, component based development may be perceived as less efficient and less effective because the efficiency and effectiveness is limited to strict compliance with the rules. As a result, breaking the rules will make component based development even more ineffective and inefficient which encourages the decision makers to reject the approach altogether.

Is component based development doomed to fail by its success? How can we prevent that from happening?