There IS a Silver Bullet

There IS a Silver Bullet is an article by Brad Cox from Byte magazine – the October 1990 issue. In it Brad argues that a software industrial revolution based on reusable and interchangeable parts will alter the software universe. Now lets put this article into context. The object revolution was just hitting its peak with Smalltalk, Ada and C++ among others having either created or grown up through the 1980s – for example, C++ was about five years old. CASE tools like TIs IEF or Cincoms Mantis were being used to generate mainframe and client server apps. And Data modeling was moving out of entity relationship diagrams into dataflow diagrams and other higher abstractions that took into account dynamics as well as the static definition of database schema.

Coincident with rapid software maturations there was also rapid devlopement on the hardware side with PCs making the transition from character mode to bitmap GUI, from standalone to LAN and from File Server to Client Server applications. So Brads vision is remarkable because he foresaw a transition from classic procedural langauge like C, PLI, Cobol, Algol to object oriented languages like Ada, C++, Smalltalk, Objective C and upcoming Oak/Java. But in addition, Brad anticipated the development of object based components – and these components would be at different levels or scales of applicability.

The driving force for this transition would be the ability of object level languages to deliver software as components at different scales. Brad used the analogy with computer hardware:
Gates – correspond to expressions , conditionals, statements and code snippets;
Blocks – align roughly with routines, functions, code macros, interfaces;
Chips – comprise messages, instances, code templates, applets, servlets and beans;
Cards – map to tasks, streams, exceptions, packages, and patterns;
Racks – are represented by processes, pipes. signals, frameworks, patterns & Web services;
Now Brad proved to be very prescient, forecasting the need for components to be delivered at different scales. In contrast see Dr. Carma McClures Reuse-Re-Engineering the Software process in the September 1994 issue of Managing System Development. This article does have an excellent reuse message but lacks the vision to see components at different scales and how reuse motivations and incentives differ depending on the scale and associated practices. Meanwhile, each of Brads levels have been filled in with later innovations as indicated with the italicized entries. The only thing missing from this article was insight where the most rapid use of components would take place – on the Web and in GUI development. But Brad had only inklings of the web while VBX and JavaBeans were yet to be produced. The other missing ingredient – the pervasive use of frameworks and the expansion of basic language libraries from a few hundred routines to an order of magnitude larger with thousands of routines available in C/C++ frameworks plus Java and .NET base libraries. But all in all an exceptionally good preview of what was to come in software development.

What Happened ?

Yet despite the Silver Bullet(s) the 1990s saw an IT project failure rate of 50% – that is the project did not complete or if completed the system was not used or abandoned. By the end of the decade that failure rate had dropped to 25-30% but the failure rate of large projects over $1million dollars remained high at over 40% (see the Standish Groups Chaos reports ). What Happened ?

The Silver Bullets were available but IT project failure rate remained large. One can discern at least three major reasons for this phenomenon:
1)the rate of technical change in computing accelerated in the 1990s with PC software reaching maturity; but new challenges with the Web, n-tier processing, huge growth in storage capacity (and all the opportunity but also problems that brings), plus the evolving new OO paradigm;
2)the bill for “rignoring” standards with rampantly proprietary software finally came due – n-tier heterogeneous systems demand integration and interoperability; but the major software players both on the PC and in the enterprise like IBM, Lotus, Microsoft, Oracle and others were primarily dealing proprietary cards;
3)many projects were failing for political and management of change reasons – they were not technically deficient they were all stakeholders best interests deficient. The hard spade work of getting all parties not just agreeing but positively contributing to IT projects for a number of reasons fell by the wayside.

So dont blame Brad – he helped define and provide one of the key necessary enablers – the move to component software on a complete scale from routines all the way up to todays software darlings, Web services. And during the 1990s one can see from our list of italicized innovations the Silver Bullets didnt tarnish but actually got polished and enhanced. At worst, Brad can be blamed for not providing a list of necessary and then sufficient conditions for development success. But this was not his goal. Rather, IT analysts, consultants, and Business schools should shoulder the major blame. Because the problem of IT failure rates has persisted 50-60 years.

IT projects are fundamental to an organization because they change the information, control and creative decision making processes and workflows within an organization. This means fundamental change everytime an IT project gets done because processes, workloads, responsibilities and the corresponding rewards/compensation may or often do not get changed to correspond with the new “system” or work environ created by IT systems and change. In effect, what I am saying is that despite unprecedented spending on consultants and analysts as to the “why and what” to get done; organization have time and again have failed on the questions of “when, how much and exactly how” to implement and deploy IT effectively in an organization. I call this continuing plague on IT projects The MisManagement of Change. We have gone beyond, well beyond the mythical man-month.

(c)JBSurveyer