Slashdot Mirror
Mob Software
Hell O'World writes: "Wow! Mob Software." A concise submitter, how refreshing. To elaborate: an essay whose author argues that large software projects should be built, well, by a mob.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
At first glance, I thought he was talking about a database to keep track of whose kneecaps to break, with a friendly MS Word'esque helper with the face of Tony Soprano telling you "It looks like you're tryin' to write a fsckin' business letter." Then I actually read the article. . .
- Relativistic? That's barely Newtonian!
How can we say it's mob software, when that implies that "noone in the group is regarded as important".
Think about it. What do we use? Is Linux Kernal truly mob software, or is it, more likely, gang software, a gang with one or two clearly defined individuals who are regarded as important, but who can be replaced and the gang continues.
A mob has no leader per se, no conscience. But a gang has one or more leaders.
I know, one of my great-uncles came up with some of the theories and observations of how people act in gangs and mobs, and how very few of us can resist going along with mob sentiment.
--- Will in Seattle - What are you doing to fight the War?
A software methodology that has a stupider name than "X-Treme Programming"
Trolls throughout history:
Jonathan Swift
Secondly, and more importantly, this article covers substantially more ground than "...&the Bazaar". Open source, for instance, is more or less taken as a given, which makes sense since Gabriel has been hacking since the 70's...
But what you perceive as poetry is really the meat of the argument. Gabriel is trying to employ reasoning from Christopher Alexander's "A Pattern Language" to demonstrate how we should build software. The OO pattern guys have read this book, but they have only figured out the fully technical aspect. Gabriel is writing about the patterns of software that pursue Quality, and one of the dominant ones is that the users are the developers, and vice versa.
As an aside, he even demonstrates that cathedrals were built over generations without a written design; successive builders only shared a common Pattern. So there goes the cathedral/bazaar distinction!
Read his stuff. Then read Alexander. You'll be the better developer for it.
In addition to the stuff we all know about open source, there's a good point in here about the benefits of the quick-and-dirty approach. This idea is that too much design leads to unimplementable projects which are optimized for situations that don't actually arise; it is better to do only a little design and then implement something, so that you can find out what the implementation issues actually are.
It also talks about large systems having emergent properties. All of the examples come from nature, not computer science. To a large extent, I think that this is a mistake. It might be a good idea if you can stand a lot of unpredictability and have to deal with very messy input (like in the physical world), but seems mostly to be exemplified by Windows DLLs: you never know what will affect what, and you can't necessarily repeat something, because the conditions will be different.
I think that modularity is a much better method. This reduces the sizes of the parts that anyone has to understand: the linux kernel is pretty big, but is manageable, at least when ignoring all of the specific drivers (which essentially are constrained by simple interfaces); all of the parts of a linux system, if they were not separated out, would be totally unmanageable. If these parts are constrained, it is possible to understand.
A somewhat methodical approach is far superior to an evolutionary approach, where you essentially change things at random and see what works. While too much attention to getting things perfect as written leads to shortsightedness, not understanding the code you're writing makes for a totally unsupportable program.
You bring the pitchforks and I'll get some torches. We'll have Mozilla 1.0 out in no time!
"Prefiero morir de pie que vivir siempre arrodillado!"
Someone here wondered a few days ago how an Internet worm might succeed if it were able to mutate and evolve in a Darwinian context. This writer is wondering what software will be like when all code can evolve, and interact, and what that emergent behavior might be like.
.NET will become a monoculture on the internet -- it would be quite a surprise to suddenly find little XML packets flying around in a language nobody could understand, the fruit of some bright hacker who releases a clever little self replicator, evolving at five generations an hour.
It is both a wonderful and frightening thought -- the Internet may already be sufficiently complex for self-replicating, self-modifying code to survive in the wild - and if it isn't, it won't be too long before that becomes possible.
We are all busy wondering if Microsoft and
How long would it take for Darwinian code to evolve to the point where we couldn't eradicate it?
I think the biological model is worth paying attention to. A plague wipes out cathedral builders and bazaar merchants alike.
A customer service representative will be with me shortly.
Richard Gabriel gave this speech at theOOPSLA 2000 Conference (Object Oriented Progamming, Systems, Languages & Applications). There are some other interesting keynote presentations there including a piece on Adaptive Software Engineering (PDF Alert!!).
.pdf of the essay, or if you can't view pdf's, check out the cover.
You can download a
"My mother never saw the irony in calling me a son-of-a-bitch." - Jack Nicholson
The bigger the project, the more people should be writing it?
WOAH! Where'd that truck come from? I always thought that the bigger the project, the fewer people should work on it...
And all *my* story submissions get rejected...
Moderate away! I've got Karma and I know how to use it!
If God gave us curiosity
... no lights but for the sickly glow of hundreds of monitors... a mob of coders, all hunched over their various workstations.
Suddenly, a burly, unshaven brute of a coder stands up, thrusts an accusing finger towards another man across the room, and shouts "He's using global variables!... GET HIM!"
Pipes, chains, and two-by-fours appear out of nowhere as the entire mass of geeks converge on the poor victim, now bleating plaintively, pathetically trying to shield himself with his keyboard...
...
Yeah, I see how that could work out pretty well, actually!
This is the essay that formed Dick Gabriel's OOPSLA 2000 invited talk.
It was a really thought-provoking talk, punctuated periodically with various musical interludes. Richard himself was wearing a rather interesting outfit -- if I recall, it's been almost a year so I might be off, it was a large leather shawl... I remember a few people in the audience whispering ("is this supposed to be zen or just wierd on purpose?")
But a lot of what Richard says also highlights some of what several others (Jim Coplien, David Ungar, etc.) were hitting on during the conference: that we really aren't creating *great* software. We've certainly tried to come up with movements to do so -- from Extreme Programming, to Design Patterns, to new high-level languages. But "design patterns" aren't quite the same things that Alexander had in mind (entire "pattern languages" to emerge "great software" was the hope), and that most design patterns could really be termed "fixes for existing languages".
We need new approaches to software design -- and we need to explore more of the consequences of abstraction. Humans use abstraction as a mental necessity... but is there a way to abstract without losing the importance of the details (when they are relevant and important)? How can we handle the tremendous complexity of software when that complexity is increasing at an alarming rate?
But most importantly -- How do we teach the next generation of programmers what we've learned, so they don't make the same mistakes?
So the point of the essay (that I took away) is this: if we're going to find new approaches for software, we're going to have to create a "new literature" to learn from, as we're running out of sources of "great literature" (many of which are becoming passe').
The way to create an evolving body of code literature is through A) people that are passionate about software, B) through software that is free, and C) through software that is openly collaborated on. Hence: Mob Software...
A lot of the the themes aluded into in this essay: poetry, abstraction, software, patterns, etc. are all discussed in great detail in his book "Patterns of Software: Tales from the Community".
Cheers
-Stu
I don't know what he's talking about. There's no mob mentality on the internet. The web is a place where individuals can share unique and sometimes conflicting ideas in a positive manner. To imply that there is any kind of groupthink...
I just realized where I was. Tra la la.
"I will give you a patch you cannot refuse"
Well, it might work
/Janne
Trust the Computer. The Computer is your friend.