Mob software

Richard P. Gabriel and Ron Goldman have posted an intriguing essay
entitled Mob
Software: The Erotic Life of Code. It presents a poetic vision of
building software, with nice discussion of early Open Source, and of
gift economies.

I first saw the link to this piece on Wes Felter's excellent Hack the Planet (which just
turned three years old recently). There's also a link from lwn.

You've probably heard of Richard Gabriel - he's a Lisper from way back,
and also founder of Lucid. More lately, he instigated the Jini project
at Sun. The ideas are intriguing, to say the least.

How many great artistic works can you think of that were created
by a mob? Despite some interesting experiments by the surrealists,
it really doesn't work. Good software, and good art, can come out
of the contributions of many people, but for almost anything that
ever succeeded, the work is built around a core design that is
comprehensible to one skilled designer/artist, or maybe two or
three who understand each other's thinking so well that they work
together practically as one.

One reason why software sucks is that so much of it is already
produced just the way the authors seem to want: lots of undisciplined
people whacking away. Commericial software companies, free software,
much of it is the same: lots of people spewing out lots of code with
too little thought to design and hoping it can be fixed later.

Great masterpieces on a scale too large to be accomplished alone by
a single person are planned. Always. Must be. But this is
not antithetical to creativity, art, or the human spirit. The
authors cite the example of the OED, but the OED has the quality it
has because of the vision and determination of one individual,
who was able to enlist an army of supporters in his vision.
The vision, which was quite revolutionary at the time, was to take
a scientific approach to language: trace the origins and use of words
by their actual use, both currently and historically, rather than
just asking some learned professor for his opinion, and include
everything (well, given the constraints of the Victorian era).

Despite ESR's dictum "to many eyes, all bugs are shallow" I do not
believe that NASA would develop more reliable software with 26,000
programmer/debuggers than 260. I'd rephrase ESR's comment to something
like "given enough eyes, all shallow bugs will be found". A shallow
bug is one that can be seen to be a bug given only the local context,
for example, there's a comment followed by a conditional and the
conditions are reversed: a greater-than test rather than a less-than
test. Or, to take the classic example,

DO 10 I=1.10

(the bug that once caused a space mission to be lost) is a shallow
bug (hint: period instead of comma; spaces are ignored in Fortran,
naming a variable declares it). But deep bugs won't be found this way.

Theorem-proving would be a better bet, but that takes rigor
and training and discipline and the authors of this essay aren't turned
on by that.

We need to have the solid engineering infrastructure in place before
the wild and wooly stuff can be built on top.

Dick Gabriel is an interesting and original thinker about the state of
software engineering today. I resonate with his revisiting of the
implications of Alexander's design pattern work. But he takes a leap
of faith when inferring the phenomenom of the web implies the future
direction of software belongs to the many. He fails to differentiate
between a scripting language or markup language designed for
widespread use, and the programming languages (and programmers)
required to realize a scripting language or markup language. Sure
many environments will come into existence with emergent properties,
where the sum of users create something bigger than the original
designers dreamed of. But it will still take concentrated and skilled
efforts to create those user-friendly environments.

Sure, there will be a popular literature of scripting/markup
languages, but it will be enjoyed for the end result, not for the
intermediate representation. How many people enjoy reading HTML?
Maybe there will be a greater appreciation for design patterns (in
concrete form) among the few who create the interpreters used by the
many, if people study what others have written, and experiment with
building on top of existing foundations (or evolving those
foundations). But believe me, that has not been a widespread activity
to date. Far more people have read about Design Patterns in English
than have ever studied a Design Pattern in the source.

You can throw all the Biological, Genetic, Evolutionary, Chaordic,
Dynamic Synergistic Buckminster Fuller and Dee Hock pap you want at it,
but the only concrete point this article makes is that programming can
be a good social activity as well as an engineering discipline, and that
someday it'll likely be as widespread as writing, email, and the web in
general. I'd like to see that day like anyone else.

But I don't for a minute buy that all today's software is
"Levittown" and the future of software is a termite colony.
Software is made for a variety of reasons by a variety of people, and
each context demands a different approach.

This article is like someone bemoaning the fact that business documents
are written in "monocultural" business-speak rather than Beat Poetry,
which is clearly more Erotic, and hence better. It has a different
purpose, audience, and context, hence it turns out different.

Every time I hear the words art and software in one sentence I have a
gut feeling that there is something wrong. I do produce software for
quite some time now, and I do feel more like a craftsman, not like an
artist. I do want to produce software that works well and is useful to
the ones who buy it. Thus I am more like the carpenter that builds a
house, lots of small pieces that must be put together in long tedious
work to finally see the whole.

Art is to me somthing entirely different. Art is to express ones feeling
in some form that is understandable to others in some way.

Current software is overgrown cobwebs. Any change breaks everything, and
it has the general appearance of being old, dusty, and full of dead bugs.

What Gabriel is implicitly saying is that it's possible to make software
out of play-doh, which can be easily cut into pieces and rearranged at will.

This sounds like a joke because no software today has this quality. It
is ironic that architecture, which is much more inherently static, has
been made much more flexible in practice. I find Gabriel's hope both
plausible and inspirational. Hopefully it will make some headway into
the culture of programmers who have completely internalized getting a
pit in their stomach every time they have to alter a piece of software.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.