It's easy to take something for granted when it is invisible. Software
is the most important invisible commodity in our world, next to the
human soul. And being the product of human souls, it partakes of
their spiritual nature. Yet it remains a human invention, and the
creation of software is most often described as "software engineering." We've
been "making" software for about sixty years now, and it's
indicative of our expectations that we're inclined to think we have
a good handle on how to do so.
Those expectations are often and famously summed up with the pithy zinger, "What
can't we build software the way we build bridges?" Implied in that
statement is that we build bridges easily and with precision, based on
rational decisions and sound, well-understood mathematics. But neither
the math nor the engineering that go into modern bridge building were
at all understood only sixty years after the very first bridge was built.
Why should software be any different?
One answer might be that software development progresses at a very different
rate, in what author Scott Rosenberg calls "software time".
Like a great piece of software, 'Dreaming in Code' seeks to do many things,
and does them incredibly well. It's the product of one very talented
man, who wrote it in less time than the team of top-rate software developers
he was following used to create a buggy, crippled version of what hoped
to be visionary software. One can only hope that Chandler, the software
whose creation Rosenberg follows in 'Dreaming In Code', is even one tenth
as visionary as the book about its creation.
In 'Dreaming in Code', Rosenberg, the co-founder of Salon.com, offers
much more than a "fly on the wall" vision of the software creation
process. This is not a technical book about the bits and bytes, it's
a grand vision of where we've been and where we are, and yes, where we
might go; but not so fast. It's also a page-turning story about a compulsive
visionary, Mitch Kapor, the creator of Lotus 1-2-3, who finds that he
is not above not above what proves to be a farrago of laws pertaining
to the creation of new software. Rosenberg's book is funny, thought-provoking
and ultimately pertinent to fields far beyond the creation of software.
Any manager who thinks that they can fix a problem by simply throwing
more people at that problem had best read this book -- and any foot-soldier
thrown in such a direction would benefit as well.
Rosenberg starts the book with Chapter 0, an indication that everything
to follow is just a bit off. Once he;'s explained "software time" and
presented readers with the bridges-to-software comparison, we're dropped
in the middle of a doomed set of programmers, faced with insurmountable
challenges and undeliverable schedules. We're in OSAF (Open Software
Applications Foundation) HQ, as Michael Toy tries to wrap his brain around
the challenges presented by Chandler. That's the working title of the
software envisioned by Mitch Kapor, software millionaire philanthropist
who founded OSAF to create a piece of software that he hoped would capture "the
soul of Agenda". Agenda was a small piece of software Kapor pioneered
while still with Lotus, a sort of catchall for the sorts of information
we scribble on yellow stickies and on the backs of other people's business
cards. A small list-making program with a few bells and whistles, it
was elevated into software legends for its unique flexibility. At OSAF,
Kapor hoped to combine open-source coding with a core team of inspired
software engineers to create an information organizer that would do,
well, almost anything. It depends on who you ask and when you ask them
specifically what Chandler might do.
Bankrolled by a brilliant millionaire, OSAF attracted top minds who found
themselves thrashing and searching for direction as they tried to create
Chandler. Rosenberg interleaves his fly-on-the-wall descriptions with
a look back at the software business and the still nascent art and science
of creating software. He brilliantly brings in the experts, in particular
the seemingly prescient Frederick Brooks, and explains what we know thus
far about how to create software, which is, er, not much. Bridge-building
engineers have physics to back up their designs, while software engineers
have ... unrealistic deadlines.
The brilliance of 'Dreaming in Code' is that Rosenberg manages to clearly
explain much of what we do know about building software and then give
us a dispassionate perspective on a team of top engineers bumping up
against every limit law and useful aphorism that have been written about
the art and the science. For example, Brook's primary law is: "Adding
manpower to a late software project makes it later." You can count
on seeing Kapor and company express their understanding of that law,
then go straight out and ignore it, only to suffer the consequences.
Of course, this lesson is not applicable only to software engineering.
The book, though it stays focused on software engineering, is clearly
applicable to every other realm of life.
Rosenberg's portraits of the characters, the real people who work on
the project are sympathetic without being sycophantic or hypercritical.
We get to see the movers and shakers as they are shaking in their boots
or moving on to new projects. Kapor emerges as a driven but ruthlessly
self-critical leader who has set himself a goal that is more daunting
than he can possibly know. He's smart and funny, but not exactly likable.
He does seem, however, exactly real. We see the members of his team grow
weary or grow inspired, grow with the tasks assigned to them. Mimi Yin,
for example, starts as more of an artist, but grows to become very important
to the design of Chandler. It's a fascinating journey that offers both
personal profiles and a general overview of business, art and engineering
mashed together and asked to do something sensible.
'Dreaming in Code' is pretty consistently funny, which makes is a pleasure
to read. It's also mind-boggling in the sense that Rosenberg uses analogy
like both the coders he speaks with and science fiction writers, to make
a sort of electric connection between apparently disparate ideas. And
more than simply following a single project, Rosenberg manages to reach
beyond for the essential paradigms and lessons that lurk beneath the
details. To employ the same technique here, I might say that 'Dreaming
in Code' is 'The Peter Principle' for the information age. But
'Dreaming in Code' is an original work, a well-written vision of things
not dreamt of anyone's philosophy.