It is against the background of business need for adaptability that the "software reuse" buzz word has become so popular. About ten years ago OO methodology was seen by many as the break through, that would enable high level reuse and drastically improve software development productivity and adaptability and thus shorten lead times for the development of new software.

The experience from the last ten years has however shown that an uncontrolled use of OO methods may make things much worse and that typical productivity gains from naive use of OO technology turned out to be in the order of 20%. However, against those moderate figures there are some spectacular claims in the literature of productivity gains of up to 20 times. Why the difference?

Apparently it has now become very important to understand what are the special conditions of those spectacular success stories. Can they be reproduced in other situations? And can these gains be improved on even further?

Before giving another buzz word answer to these questions it would be helpful if one could better understand why it is so difficult to improve software productivity beyond a certain level using more conventional software engineering methods and technology. There are in fact no known methods by which one may develop large and complex software systems within a short time frame. And we have a pretty good idea why. It all comes down to the cost of communication between the developers. It is the cost of trying to get all the details of the interfaces correct and the cost of correcting the faults resulting from the inevitable failures of getting it right. Thus dividing the project in smaller and smaller units to be developed in parallel just exacerbates the communication problems.

As every software professional knows one of the most productive way to develop software is if the conceiver of the application idea develops the software on his own. This completely removes the need for interpersonal communication. If commercial software is to be produced this way we need to add independent quality control measures such as testing and continues reviews. But there is a definite limit to what size a one person projects can take. If the project increases above a certain size the interpersonal communication start to show an increased rate of failure.

Thus, not surprisingly, small groups of 2-3 dedicated software professionals can demonstrate much higher levels of software development productivity than can be reproduced in larger teams. The examples from the computing history are numerous.

By now many will expect that the left out buzz word from above would be "component computing". You will be disappointed. Component computing will no doubt play a large part in the solution of many software productivity problems, but it is the wrong answer because it is not general enough.

At MetaAgility we believe the right answer is the adoption of "Open Standards Business Adaptability Strategy" (OSBAS). This is based on the principle of simple open standards, some of which already exists. OSBAS is the only way to improve the precision in communication about software problems long term. An alternative could be to resort to the use of advanced software development CASE tools. The 20 times gains in productivity comes from software component oriented development supported by strong CASE tools.

OSBAS does not preclude the support from tools, but it prevents the lock in effect from such tools; if the standards are simple enough, it is always possible to manage without the tools or to implement the necessary tools yourself unless they are available from open source. Lock in resulting from the use of non-standard tools is on the whole counter-productive to business adaptability long term. The only temporary exception is if you for the moment happen to be locked in with the best tools for achieving adaptability. Adoption of open standards will on the other hand help you to avoid the crippling effects of lock in.

Sverker Griph, November 2001

Return to the white paper index.