COMPONENT QUALITY: THE GREAT DEBATE

by Paul Allen

What are the overall trends underlying the component quality debate, and what can we do about them? Here is a summary of the main messages.

You Can't Control What You Can't Measure

The issue of component quality is intimately connected to the question of measurement. It's interesting to note that most commentators are actually pretty vague on this subject when they criticize components. My feeling is that there is a much deeper problem at work here. Because many organizations are, on the whole, quite poor at measuring the quality of their software, they often do not have a benchmark against which they can assess the success or failure of that software. So when things go wrong, it is all too easy to blame components, especially third-party components -- a great scapegoat!

Evolve Your Methodology

Good analysis and design techniques tend to play catch-up with developments in technology. Components, and now Web services, are indeed a new technology, but we are to a large extent applying processes, architectures, and design guidelines that are applicable to older technologies. This is akin to trying to pedal a motor bike or using a character-based interface to surf the Internet.

Keep Things in Proportion

At the same time, while quality is undoubtedly a major issue, it's important to maintain a sense of perspective here. If component quality really is a massive problem, then a lack of metrics, specification standards, and effective processes certainly helps to explain this. However, I'm not so sure that component quality is the major problem, over and above quality of software in general, that the doom merchants would have us believe. It could just be that our survey is saying that component quality isn't really such a big deal, and that's why organizations aren't too bothered about measuring it. My view is that the truth probably lies somewhere between these extremes: component quality is important but not to such an extent that we should stop buying components and mistrust advocates of this technology.

Plan Your Transition to Service Orientation

Whether we like it or not, components are here to stay, and, as I've said before, the economics of reuse means that they won't go away. This is part of the wider transition to the computing utility model that involves a shift to service orientation. At the very least, every organization must now plan to separate the provisioning and consuming (assembly) processes, within the context of a dynamic change management framework. This turns up the heat on the suppliers, in terms of their ability to specify components, and equally on the consumers, in terms of their capacity to assess components. It means that the software industry has to grasp the nettle and treat specification as a top issue. Clearly, this can't happen overnight because it involves a profound cultural shift on the part of consumers and a way to achieve wide consensus on standardization on the part of suppliers. Nevertheless, it is starting to happen, as evidenced by the ComponentSource and CVC initiatives, not to mention the work of the Object Management Group in Model Driven Architecture (see CDS, January 2002) and in improving UML to better support the CBD (as opposed to the OO) paradigm.

Show Me the Money!

I would encourage organizations to guard against hype seduction: just as "reuse is not free use" components and associated technologies (such as Web services) come at a price. One element in that price is an increased emphasis on quality, especially on nonfunctional requirements. This includes component reliability, but this is only one quality attribute among many that must be weighed and evaluated in relation to one another. And measurement costs more money -- someone has to do it, and (yet more tellingly) someone has to pay for it! Another element in the price is the cost of clear component specification and the cost of applying related techniques for assessing suitability of components. We also need to factor into the price the learning curve that comes with any new technology.

Understanding Components Is Just One Piece in the Organizational Jigsaw

The biggest part of the price are the processes, architectures, and techniques that are required to successfully use component technology, along with the costs of planning and implementing the associated organizational and cultural change. For example, how do we address the following obstacles: NIH ("not invented here") syndrome, project-driven component costing, productivity measured by lines of code, the politics of ownership, top-heavy and overtheoretical process improvement initiatives, and WISCY ("why isn't Simon/Sally coding yet?") syndrome. And how do we inspire trust, introduce a collaborative and sharing culture, align business and IT activities, release core competency energy, and measure productivity in terms of business results? Not, I would suggest, through doom-and-gloom stories.

Choose Only Clearly Specified Components that Fit Your Strategy

Certainly, we should beware of poorly designed third-party components, especially those that are proprietary and mix different types of functionality (from different architectural layers). Consumers need to take care that they are not being led toward a closed environment involving an expensive learning curve with little return on investment. In a worst-case scenario, good money is thrown after bad as the technology becomes obsolete faster than you can implement each new release.

Build on Success

At the same time, a well-thought-out and executed approach to CBD can actually leverage component quality. And this doesn't just apply to reusability and performance, both of which too often receive our exclusive attention to the detriment of other equally important component characteristics. For example, the replaceability dimension of component technology is something to bear in mind as it provides the ability to plug services in and out as they mature and become available, thus helping the organization adapt quickly to new business opportunities.

--Paul Allen, Editor, Component Development Strategies