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?

Advertisements

About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of CM, Agile development and ALM. I am strongly interested in the complexities of collaboration and integrations in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in configuration management. Bookmark the permalink.

3 Responses to Nightmare of component based development (3)

  1. Damon Poole says:

    Hi Frank,So, what is the follow-up to these posts on component-based development? How have things evolved since you posted this?

    Like

  2. Frank says:

    Hi Damon,Thanks for the reminder. I will write something about it.

    Like

  3. Andrew Mc andrtew.mcgrath@jkgroup.com.au says:

    Funny reading this – realise its a while ago but component based design (or OO) has shown to be the best thing thats happened to us in a long time.The difficulties u mention such as defining which tasks should come first in terms of priority and general implementation requirements…generally sort themselves out if the design is done properly in the first place. Failing that, a little bit of planing and consideration (maybe even dummy compoent / objects) often solve theses issues again.Have you had similar experiances? Reading a lot of the old material from 1996 onwards, seems to contradict what the industry has discovered.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s