Chapter 3: Rapid Prototyping for Fun and Profit

The Ramans do everything in threes.

Arthur C. Clarke, Rendezvous with Rama

3.1 Knowledge and the learning curve

If you take a random walk down Wall Street, you'll soon discover that the average amateur investor doesn't know what he's doing. To make money in the stock market, everyone knows you must buy low and sell high. Yet year after year, the wolves fleece the lambs out of millions of dollars. It's well documented that the little guys—meaning you and I—are usually wrong at critical turning points in the market.

Many institutional investors don't do much better either. Most pension fund managers, mutual fund portfolio managers, and professional money managers have displayed an uncanny inability to beat the market consistently year after year, though many command annual salaries over a million dollars.

Studies have shown that index funds, which invest in securities represented by an index such as the Standard & Poor's 500, have outperformed 77 percent of all mutual funds on a long-term basis. Despite the hype in the financial world about hot investment opportunities, the published records elucidate a stark reality: Most of us can do about as well as any other investor, amateur or professional, by throwing darts at the stock pages of the newspaper and buying the stocks found thereunder.

Although it is extremely difficult to beat the market consistently, some do. Peter Lynch, renowned former manager of the Fidelity Magellan Fund, racked up an impressive record in the 1980s, making his clients very wealthy. Warren Buffett, the "Oracle of Omaha," has reaped enormous profits for stockholders in Berkshire Hathaway. Sir John Templeton has made similar fortunes by seeking investment bargains the world over.

Despite their successes, these legendary investors readily admit that they don't always get it right. They tell stories of the companies in which they had complete confidence whose stocks lost over half of their value in the year they purchased them. They lament the "ones that got away," the unlikely stocks that went on to score in the 1,000 percent range and higher. Although their performance far exceeds the norm in investing, they know that they still have a lot to learn.

Other professionals have a lot to learn, too. Doctors must constantly strive to remain abreast of recent medical research developments. Accountants must learn new changes in the tax laws. Lawyers must study recent court decisions. Actuaries, salespeople, truck drivers, assemblers, plumbers, fashion designers, judges, researchers, construction workers, and engineers all have something to learn.

3.1.1 The fact is, everyone is on a learning curve

Think about it. When was the last time you met someone who knew the exact result of an action every time without fail? I'm not saying that such people don't exist. I'm only suggesting that they are rare. Such ability usually requires plenty of hard work and study, plus a dose of good luck.

Engineers offer perhaps the best living proof that most people are still learning. For example, if aeronautical engineers know everything there is to know about aeronautics, then why do they need test pilots? Why do General Motors' engineers road-test their cars? Why do computer engineers subject their products to a field test before putting them into mass production? If engineers had complete knowledge of what they were doing, quality assurance departments would be unnecessary because the quality would be built into the products during the developmental phase.

Unix engineers would write all of their programs using the cat ^[1] command.

Software engineers are particularly burdened with a steep learning curve. Software is difficult to write correctly the first time. The software engineering profession consists of constant revision, a job where trial and error are the norm, and applications are born out of countless hours of frustrating rework.

Note that we're not saying that people can never master anything. It's just that it takes longer than most people suspect. The average learning curve extends further and inclines more steeply than it first appears. So many variables exist in the world today that mastery can consume a lifetime, and complete knowledge may not even be attainable at all.

3.1.2 Even the masters know that changes are inevitable

It's a rare project indeed that doesn't require changes to the original specifications. Marketing requirements shift. Suppliers fail to deliver. Critical components may perform differently than specified. Prototypes and test runs expose design flaws. These factors make producing sophisticated technology the most delicate of tasks.

Faulty communication frequently bears the responsibility for the necessity of changes. When a product's prospective end user tries to explain his needs, many gaps exist in the description. He may omit something or perhaps fail to convey with sufficient accuracy the details of what he has in mind. So the engineer uses his imagination to fill the gaps. He takes the description, looks it over, and begins to apply his own biases to the design. Sometimes the engineer tries to second-guess the end user or assumes "he really wants it this way, not that." Even worse, the engineer is often separated from the end user by corporate individuals, such as product managers, the sales team, and support personnel, who add further distortion to the end user's desired outcome.

We see through a glass darkly. Beyond the smoke and mirrors, experience dictates that we will not get it right the first time. It's better to face this axiom up front. Building into the design the assumption that changes will be needed later can reduce the cost of undertaking major revisions later when the goal is better understood.

3.1.3 Why do you think they call it software?

Software engineering requires more rework than any other engineering discipline, because software deals with abstract ideas. If people have difficulty describing hardware accurately enough to get it right the first time, imagine how difficult it is to describe something that exists only in peoples' minds and in electrical patterns traversing a microchip. The admonition, "Abandon all hope, all ye who enter here" comes to mind.

If end users could specify precisely what they wanted—if software engineers had complete knowledge of users' needs today and in the future—then we would not need software. Every program written would be placed in read-only memory (ROM) the first time around. Unfortunately, such a perfect world doesn't exist.

In my early days as a software designer, I used to strive for software perfection. I would write and rewrite subroutines until they were as fast and clean as they could be. I reviewed code repeatedly, hoping to make it even marginally better. I added new features (creeping featurism, really) as the ideas for them came along. I blissfully carried out this exercise until my boss snapped me back to reality.

"It's time to ship it," he declared.

"But it's not done yet! Just give me a couple more days to …"

"Software is never finished. It is only released."

Once a piece of software is released, no one really knows what will happen to it. Experienced engineers may have a vague notion of the consumer's demographics, the kind of environment it will be used in, and so on. But they would be hard pressed to predict reliably the eventual success or failure of any software product.

At one point, I worked as a telephone support engineer for a large computer corporation. After having worked for many years engineering the operating system, I found myself on the other side of the fence, answering questions on the programs we had written. This experience was a real eyeopener. When you're working in engineering, it's easy to fall prey to the notion that you have everything under control, that, by golly, you know how people are going to use your software.

Wrong. You may think you know what your users are going to do with your software. But what engineer, safe in his Dilbert cubicle, surrounded by engineers with advanced degrees, could have realized that:

• One Wall Street firm would lose more than $1 million an hour because of a kernel bug that kept crashing the system during the trading day. The firm was so upset that it installed a competitor's system a week later. A month later, they reinstalled the original system because, despite its flaws, it was the more reliable of the two.

• An oil company would use a system to do seismic sweeps in the Gulf of Mexico to search for oil deposits. They would acquire gigabytes of data per day, necessitating the use of more than ninety large hard drives on a system cluster. All of the data had to be available at all times. For security reasons, no one geologist could hold the key to access all of the data for fear that the individual would run off with the multibillion dollar knowledge of where next to drill for oil.

• A telecommunications company that was stashing over 10 million records per day in a database was designing a new system that would allow them to insert over 100 million records per day. Handling over 1,000 database insertions per second was difficult enough. Now they had to handle peak periods of as many as 5,000 insertions per second.

• An electric utility had one system that was the central controller for the electric power grid of one of the largest states in the United States. An outage would leave millions of people without power until the system was fixed.

The Unix developers certainly didn't know what would happen to Unix. Nor did the developers of MS-DOS, OpenVMS, and every other operating system for that matter. Every new OS—and Linux is no exception—takes its designers into uncharted waters. Their only hope consists of continually gathering progress reports and then correcting the course accordingly.

For example, did Ken Thompson realize the importance of portability when he wrote the first Unix kernel? Evidently not, for he wrote early Unix kernels in assembly language. He rewrote them later in a higher-level language, altering his original direction. Did Dennis Ritchie anticipate that C would become a universal programming language, loved and abhorred by millions of programmers? Hardly. The reissue of his classic The C Programming Language contained modifications to the language specification that affirmed that he didn't get it right the first time either.

So most of us are still learning. Even if we're egotistical enough to think that we know it all, someone will change the requirements on us. How then are we to build software? The next tenet holds the key.

^[1]One of the simplest of all Unix commands, cat directs everything that a user types into a file. Unlike a text editor or word processor, however, the cat command doesn't allow one to modify the text on previous lines.