From faslanyc a review of a seminal article from computer programing which has relevance to all those who are involved in design in the city – how much we drive topdown “perfect planning” and how much we are able to relinquish this to a more “crowd-sourced” participation is questioned.
[a bazaar in Baghdad; image from flickr user micmol]
The other day we were spending a little time with Eric Raymond’s seminal essay “The Cathedraland the Bazaar”. We do it periodically as a way of self-medicating against the annoying notion of emergent urbanistic ideologies bandied about in the halls of higher learning, and as a reality check for our own childish notions. The 1997 essay about the design lessons learned from the Linux system is full of insightful, potent jewels that might inform new models of landscape practice. More important, simply reading this nerdy computer man’s essay is an aesthetic experience:
Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.
Linus Torvalds’s style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.
Throughout the essay Raymond pays extra attention to the mechanics of the Linux system and his materialist analysis leads to surprising conclusions which are cleverly titled with captions such as “Release early, release often” and “On Managementand the Maginot Line”. When diving in to details such as Linux kernel release mechanisms he bores down in on them, nerdily fumbling them around in his hands, poking it with sticks, and examining them under looking glasses.
My original formulation was that every problem “will be transparent to somebody”. [Linux creater] Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. “Somebody finds the problem,” he says, “and somebody else understands it. And I’ll go on record as saying that finding it is the bigger challenge.”
In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena… In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.
But the problem with being clever and original in software design is that it gets to be a habit—you start reflexively making things cute and complicated when you should be keeping them robust and simple.