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)
"The builders shared a set of principles--the common pattern language."
Slashdot is, in its own, chaotic way, from the folks posting "goatse.cx" links to the helpful mirror-site posters, from the "Frist prost!" guys up to folks like Perens and Carmack, the place where engineering minds of many feathers come together, and as a group, we are able to keep in touch not just with news, culture, and technology, but to keep in touch with a common understanding and culture.
We ARE the mob.
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?
``"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
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.
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
Do we really need another organized crime syndicate in the software business?
After all, we've already got Microsoft.
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
Isn't this basically just the standard Open-Source development model, but restated with a lot more cool poetry?
Perhaps that's not "Mob Software's" point -- perhaps the whole point is just a romanticization of The Bazaar. I'm cool with that.
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
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!
...something about an infinite number of monkeys on an infinite number of typewriters. It could work... :)
"Your superior intellect is no match for our puny weapons!"
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
IBM Project. $900 million spent, NOTHING delivered.
-nuff said.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I get the news I pay for, I guess.
--hongpong.com
This sounds like a couple of guys who are unable to let go of the heady, exciting days of software development in its infancy, and move to the next stage.
Certainly mob creation has it's role in any industry, but as the industry matures, the place for the mob changes. Early on, each element of the mob was a person, creating operating systems, computers. As time has gone on, a person is no longer capable of creating a big application or designing a computer themselves. So now an element of the mob is a design team, or a company. And cooperating in our mostly free market, they act as a mob.
Even within a given time period of an industry, mob development works better in some places than others. The Linux movement? sure, the mob is working well. But the space shuttle code? They honestly and truly believe that something akin to the open source community should have designed the space shuttle code? Sure, the mob mentality would work, IF YOU HAD 20 SPACE SHUTTLES TO THROW AWAY IN SPECTACULAR FIREBALLS BEFORE IT WAS FINISHED.
Yes, disasters and mistakes are the hallmarks of any engineering endeavour, but that doesn't mean we can't try to avoid them.
If your only tool is a hammer...
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.