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)
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?
``"Let's have a whole bunch of people try real hard for a real long time, and eventually all the (rockets/software) that doesn't work will explode, leaving us with stuff that works".
``Oh golly.''
Yes, but ya know...that's really what happens -anyhow-! That's the engineering process in a nutshell. There's a great book called "Design Paradigms" by Henry Petroski that covers, essentially, the history of bridge building. And with each new bridge-building process, there's at least one spectactular failure and one spectacular success. And although the book focuses on the difference between good engineering and bad, reading it, you realize that that statement is not a prescription for how engineering happens, but a description of how it happens.
We keep building bridges until one breaks. Then, we find a new principle.
On the subject of large software projects being worked on by lots of people:
This is an opinion shared by a huge number of developers.
Inexperienced developers.
Everyone thinks that more people working on one project can only be a good thing, that every one of those has valuable experience and insight and should therefore have input in the decision making process.
Every experienced developr out there would agree with me that this is the best way to kill a project, mire it in personal squabbles whenever someone's precious idea is thrown out in favour of another.
No amount of non-spell checked rubbish is going to make the 'mob' mthod of software development work.
Successful open source projects have command and control systems. They don't just grow on trees.
The biological analogy doesn't hold. No one would buy a car that was as flaky as a body. The point of machines is that they're machines, not organisms. They're highly predictable and apply to a restricted problem domain. That's why they can do things we can't.
Tim
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.
In a work for pay environment- you are right.
In a work for fun environment, people self-select where what and how they program. If they have a fundamental disagreement they fork.
One may win out when his software gets used more often. Sometimes theyre both right, and they become two separate programs that serve separate users.
'Mob' software works in the sense that it is self organizing, and arises out of individual behaivhor.
Youll never see an ant forced to work in a way it doesnt want to. It does what it does from its own volition. Youll also never see two ants fight over an anthill-design issue. They work as if alone, yet together, act as single whole.
It seems that chaos is the quickest path to order.
As long as you have some organization, it will work, though. Er, Linux?
/Brian
This is an essay worth reading once to get the idea of, and a second time to get a real sense of what it means to you.
Slashdot comments are a little too ephemeral to get anything except for ridiculous jokes and twitch-trigger half-understanding out of this.
In short, it's too big for Slashdot. Slashdot is a forum built around the topical and momentary. I'm going to really wrap my head around this before I say anything about it. This essay really demands that sort of effort.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
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