by: Thomas Meloche

Heading to Extremes

The transition from procedural development to object development is significant. Object technology, properly applied, offers a substantial opportunity for software development organizations to capitalize on existing software resources. Those of us involved in object-oriented software development believe it can produce tremendous benefits providing more features while saving time and money.

This paper provides a historical perspective on why we want to develop with objects. It is hoped that by viewing the benefits component technology has provided other industries, we may be able to draw some useful parallels to our own software development industry.

The Software Development Dilemma

Before going further it is important to note that the software development industry is in crisis. Over the past 30 years software has undergone a geometric increase in complexity. Ever faster personal computers, graphical user interfaces, networks, client server, distributed systems and the Internet have all worked together to significantly increase the complexity of software.

At the same time users of computers have also grown to be increasingly sophisticated. Having learned what computers are capable of, users now request more features, better user interfaces, better error handling and data recovery. And, while demand for software is growing, supply of programmers is not. Ironically, there are currently fewer students of Computer Science in our American universities now than there were in 1985.

Our current development processes and practices are not coping adequately with these dynamic forces - it is estimated that well over two-thirds of all software development projects experience major problems and a quarter of them fail outright.¹ We must find better ways to develop software.

A Historical Perspective: 18^th Century Muskets

In the 18^th Century a typical American settler owned a musket, ostensibly for the purpose of hunting for food and self-defense. The musket, essential to the survival of the frontiersman, was custom made and handcrafted. There was no mass production. Each musket produced was unique; the work of a craftsman, an artisan, and its quality was a function of the artisan's personal ability. The quality of the musket was demonstrated only in its use - did it shoot straight? If the musket failed, it required custom repairs, again the work of the craftsman. All of this custom work, from the creation of the musket to the handcrafted repairs, were costly.

Fortunately for the artisans, the musket was considered essential, so people were willing to bear the financial burden of its manufacture and maintenance. Fortunately for everyone who needed muskets, the world of 18th Century manufacturing was soon to change.

19^th Century Revolution

At the dawn of the 19^th Century a series of inventors, including the notable Eli Whitney, experimented with revolutionary new manufacturing methods. At the core of the methods is the use of standardized and interchangeable parts. The concept is simple enough; carefully manufacture a set of parts built to pre-specified standards and test the parts against those standards. Any given complete set of these parts can be assembled to build the product. 

There were multiple benefits to this new process:

Move ahead 200 years. How does our understanding of 18^th Century Muskets relate to 21^st Century software? To see, we will start in the last century, the 20^th century.

20^th Century Software

In the 20^th Century a typical American corporation owned software. This software, essential to the survival of the corporation, was often custom made and handcrafted. Each program produced was unique; the work of craftsmen, and its quality was a function of the artisans' personal abilities.

The quality of the software was verified by its use - did it produce the correct final result? A failure in the software required custom repairs, again the work of the artisans. All of this custom work, from the creation of the software to the handcrafted repairs, was costly. Fortunately for the artisans, software was considered essential, so people were willing to bear the financial burden of its construction and maintenance. Fortunately for everyone else who needed new software, the world of software development was soon to change.

21^st Century Revolution

At the dawn of the 21^st Century a series of inventors are experimenting with a revolutionary new software-manufacturing model. At the core of the model is the use of standardized and interchangeable parts. The concept is simple enough; carefully manufacture a set of parts built to pre-specified standards. Any given set of these parts can be assembled to build the software product. We call these standardized and interchangeable parts, object or components. Using component technology, we expect to see software production experience the same benefits achieved by 19^th Century manufacturers such as:

These benefits will be realized in the 21^st Century. However, as the manufacturing processes of our ancestors had to change to embrace the industrial revolution, our software development processes must change to embrace the software revolution. Waterfall development practices must give way to iterative and incremental development practices. Test-at-the-end artisans must give way to test-first design disciplines. 

The mass production method of Eli Whitney must have seemed extreme in the 18^th century just as Kent Beck's software practices seem extreme today. But the change will be made; efficiencies in the economy make it certain.

Do not expect to move effectively from one form of manufacturing to another without changing how the entire development organization operates. As we moved from hand crafted software to mass produced software the software artisan practices will be replaced by software factory practices. Having personally participated in the creation of an XP "Java Factory" and seen the benefits realized first hand, I know that I will never go back.

¹ Standish Chaos Report [2001]