Despite my sunny forecast for the network economy, there is much
about it that is worrisome. These are the same concerns that accompany
other large, decentralized, self-making systems:
As companies become disembodied into some Barlowian cyberspace, they
take on the character of software. Clean, massless, quick, useful,
mobile, and interesting. But also complicated and probably full of bugs
no one can find.
If the companies and products of the future become more like software of
today, what does that promise? Televisions that crash? Cars that freeze
up suddenly? Toasters that bomb?
Large software programs are about the most complex things humans can
make right now. Microsoft's new operating system had 4 million lines of
code. Naturally Bill Gates claims there will be no bugs in it after the
70,000 beta-test sites are done checking it.
Is it possible for us to manufacture extremely complex things without
defects (or even with merely a few defects)? Will network economics help
us to create complexity without any bugs, or just complexity with
Whether or not companies become more like software themselves, it is
certain that more and more of what they make depends on more complex
software, so the problems of creating complexity without defects becomes
And in an age of simulations, the problem of verifying the truthfulness
of a simulation is the same type of problem as testing massive complex
software to determine whether it is or is not flawless.
David Parnas, a Canadian computer scientist, developed a set of eight
criticisms of President Reagan's "Star Wars" (SDI) initiative. He based
his criterion on the inherent instabilities of extremely complex
software, which is what SDI essentially was. The most interesting of
Parnas's points was that there are two kinds of complex systems:
continuous, and discontinuous.
When GM tests a new car on its track field, it puts the car through its
paces at different speeds. It will test how it handles a sharp curve
going at 50, 60, 70 mph. To no one's surprise, the car's performance
varies continuously with the speed. If the car passed the curve test at
50, 60, and 70 mph, then the GM engineers know -- without explicit
testing -- that it will also pass at all the intermediate speeds of 55 and
They don't have to worry that at 55 mph the car will sprout wings or go
into reverse. How it behaves at 55 will be some interpolated function of
what it does at 50 and 60 mph. A car is a continuous system.
Computer software, distributed networks, and most vivisystems are
discontinuous systems. In complex adaptive systems you simply can't rely
on interpolated functions. You can have software that has been running
reliably for years, then suddenly, at some particular set of values
(63.25 mph), kaboom!, the system bombs, or something novel emerges.
The discontinuity was always there. All the neighboring values had been
tested but this particular exact set of circumstances had not. In
retrospect it is obvious why the bug caused the system to crash and
perhaps even why one should have looked for it. But in systems with
astronomical numbers of possibilities, it is impossible to test every
case. Worse, you can't rely on sampling because the system is
A tester can have no confidence that unexamined values in extremely
complex systems will perform continuously with examined values. Despite
that hurdle there is a movement toward "zero-defect" software design.
Naturally it's happening in Japan.
For small programs, zero is 0.000. For extremely large programs, zero is
0.001, and falling. That's the number of defects per thousand lines of
code (KLOC), and it is just one crude measure of quality. The methods
for attaining zero-defect software borrow heavily from the Japanese
engineer Shigeo Shingo's pioneering work on zero-defect manufacturing.
Of course, computer scientists claim, "software is different." It
duplicates perfectly in production, so the only problem is making the
In network economics the major expense of new product development stems
from designing the manufacturing process and not designing the product.
The Japanese have excelled at designing and improving processes;
Americans have excelled at designing and improving products. The
Japanese view software as a process rather than product. And in the
dawning network culture, more and more of what we make -- certainly more
and more of our wealth -- is tangled up in symbol processing which
resembles code more than corn.
Software reliability guru C. K. Cho admonished the industrialist not to
think of software as a product but as a portable factory. You are
selling -- or giving -- a factory (the program code) to others who will use it
to manufacture an answer when they need one. Your problem is to make a
factory that will generate zero-defect answers. The methods of making a
factory that produces perfectly reliable widgets can be easily applied
to creating a factory that makes perfectly reliable answers.
Ordinarily, software is constructed according to three centralized
milestones. It is first designed as one big picture, then coded in
detail, then finally, near the end of the project, it is tested as an
interacting whole. Zero-defect quality design proceeds by thousands of
distributed "inchstones," instead of a few milestones. Software is
designed, coded, and tested daily, in a hundred cubicles, as each person
works on it.
The zero-defect evangelists have a slogan that summarizes network
economics: "Every person within a company has a customer." Usually that
customer is the coworker you hand your work off to. And you don't hand
off your work until you've done the milestone cycle in
miniature -- specifying, coding, and testing what you made as if you were
When you ship your work to your customer/coworker, she immediately
checks it and lets you know how you did, reporting errors back to you,
which you correct. In essence, software is grown from the bottom up in a
manner not unlike Rodney Brooks's subsumption architecture. Each
inchstone is a small module of code that works for sure, and from which
more complex layers are added and tested.
Inchstones alone won't get you zero-defect software. Underlying the zero
goal is a key distinction. A defect is an error shipped. An error
corrected before shipping in not a defect. Shingo says, "What we
absolutely cannot prevent are errors, but we can keep those errors from
generating defects." Therefore, the task of zero-defect design is to
detect errors early and rectify them early.
But that much is obvious. The real progress comes from identifying the
cause of the error early and then eliminating the cause early. If a
worker is inserting the wrong bolt, institute a system that prevents the
incorrect bolt from being inserted. To err is human; to manage error is
The classic Japanese invention for error prevention is a "poka-yoke"
system -- making things foolproof. On assembly lines, cleverly simple
devices prevent mistakes. A holding tray may have a specific hole for
every bolt so that if there are any bolts left the operator knows he
missed one. An example of poka-yoke for software production is a
spell-checker that doesn't allow the programmer to type a misspelled
command or even to enter an illegal (illogical) command. Software
developers have an ever widening choice of amazingly sophisticated
"automatic program correction" packages that check ongoing programming
to prevent typical errors.
State-of-the-art developer tools perform meta-evaluations on a program's
logic -- "Hey, that step doesn't make sense!" it says -- eliminating logical
errors at the first chance. A software industry trade magazine recently
listed almost a hundred error test and removal tools for sale. The most
elegant of these programs offer the creator a legitimate alternative,
just as a good spell-checker does, to correct the error.
Another poka-yoke of great importance is the modularization of complex
software. A 1982 study published in the IEEE Transactions on Software
Engineering revealed how the same number of lines of code broken up into
smaller subprograms would decrease the number of faults, all other
things being equal. A 10,000-line program in one hunk would exhibit 317
faults; when broken into three subprograms, 10,000 lines would total a
lesser 265 faults. The decrease per subdivision follows a slight linear
function, so fragmenting is not a cure-all, but it is a very reliable
Furthermore, below a certain threshold, a subprogram can be small enough
to be absolutely free of defects. IBM's code for their IMS series was
written in modules of which three-quarters were entirely defect free.
That is, 300 out of 425 modules had zero defects. Over half of the
faults were found in only 31 of the modules. The move toward modular
software, then, is a move in the direction of reliability.
The hottest frontier right now in software design is the move to
object-oriented software. Object-oriented programming (OOP) is
relatively decentralized and modular software. The pieces of an OOP
retain an integrity as a standalone unit; they can be combined with
other OOP pieces into a decomposable hierarchy of instructions. An
"object" limits the damage a bug can make. Rather than blowing up the
whole program, OOP effectively isolates the function into a manageable
unit so that a broken object won't disrupt the whole program; it can be
swapped for a new one just like an old brake pad on a car can be swapped
for a better one. Vendors can buy and sell libraries of prefabricated
"objects" which other software developers can buy and reassemble into
large, powerful programs very quickly, instead of writing huge new
programs line by line. When it comes time to update the massive OOP, all
you have to do is add upgraded or new objects.
Objects in OOP are like Lego blocks, but they also carry a wee bit of
intelligence with them. An object can be similar to a file folder icon
on a Macintosh screen, but one that knows it's a folder and would
respond to a program's query for all file folders to list their
contents. An OOP object could also be a tax form, or an employee in a
firm's database, or an e-mail message. Objects know what tasks they can
and can't do, and they communicate laterally with each other.
Object-oriented programs create a mild distributed intelligence in
software. Like other distributed beings, it is resilient to errors, it
heals faster (remove the object), and it grows by incrementally
assembling working subunits.
The 31 error-filled modules mentioned earlier that were found in IBM's
code beautifully illustrate one characteristic of software that can be
used to achieve sigma-precision quality. Errors tend to cluster. Zero
Defect Software, the bible of the movement says, "The next error you
find is far more likely to be found in the module where eleven other
errors have already been found, rather than in the module where no
errors have been found." Error clustering is so prevalent in software
that it is known as the cockroach rule of thumb: where there is one
error seen, another twenty-three lurk unnoticed.
Here's the remedy, according to the Zero bible: "Do not spend money on
defect-prone code, get rid of it. Coding cost is nearly irrelevant
compared to the cost of repairing error-prone modules. If a software
unit exceeds an error threshold, throw it out, and have a different
developer do the recoding. Discard work in progress that shows a
tendency toward errors because early errors predict late errors."
As software programs mushroom in complexity, it becomes impossible to
exhaustively test them at the end. Because they are discontinuous
systems, they will always harbor odd corners or a fatal response
triggered by a one-in-a-million combination of input that eluded
detection of both systematic and sample-based testing. And while
statistical sampling can tell if there are likely to be faults left, it
can't locate them.
The neo-biological approach is to assemble software from working parts,
while continuously testing and correcting the software as it grows. One
still has the problems of unexpected "emergent behaviors" (bugs) arising
from the aggregation of bugless parts. But there is hope that as long as
you only need to test at the new emergent level (since the lower orders
are already proven) you have a chance -- and you are far ahead of where
you'd be if you had to test for emergent bugs along with deeper
Ted Kaehler invents new kinds of software languages for his living. He
was an early pioneer of object-oriented languages, a codeveloper of
SmallTalk and HyperCard. He's now working on a "direct manipulation"
language for Apple Computers. When I asked him about zero-defect
software at Apple he waved it off. "I think it is possible to make zero
defects in production software, say if you are writing yet another
database program. Anywhere you really understand what you are doing, you
can do it without defects."
Ted would never get along in a Japanese software mill. He says, "A good
programmer can take anything known, any regularity, and cleverly reduce
it in size. In creative programming then, anything completely understood
disappears. So you are left writing down what you don't know....So,
yeah, you can make zero-defect software, but by writing a program that
may be thousands of lines longer than it needs to be."
This is what nature does: it sacrifices elegance for reliability. The
neural pathways in nature continue to stun scientists with how
non-optimized they are. Researchers investigating the neurons in a
crayfish's tail reported astonishment at how clunky and inelegant the
circuit was. With a little work they could come up with a more
parsimonious design. But the crayfish tail circuit, more redundant than
it perhaps needed to be, was error free.
The price of zero-defect software is that it's over-engineered,
overbuilt, a bit bloated, and never on the edge of the unknown where Ted
and friends hang out. It trades efficiency of execution for efficiencies
I asked Nobel Laureate Herbert Simon how zero-defect philosophy squared
with his concept of "satisficing" -- don't aim for optimization, aim for
good enough. He laughed and said, "Oh, you can make zero-defect
products. The question is, can you do it profitably? If you are
interested in profits, then you need to satisfice your zero defects."
There's that complexity tradeoff again.
The future of network economics is in devising reliable processes,
rather than reliable products. At the same time the nature of this
economy means that processes become impossible to optimize. In a
distributed, semiliving world, goals can only be satisficed, and then
for only a moment. A day later the landscape has changed, and another
upstart is shaping the playing field.