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.
Actually, the biological analogy holds up just fine. The command-and-control mechanisms in a human are awesome - far more sophisticated and reliable than those in a car. That's why a car can't juggle.
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.
Has a mob ever built a cathedral? Has a Mob ever written poetry? Part of what makes a 'Mob' a mob is its mindlessness, its random application of its great energy and enthusiasm. A team or an army is far more productive. The only thing inviting about a mob is that it's activities are generally free.
Now, regarding the actual text. Termite behavior can be likened to herd behavior. The reason you see more organized pursuits when there are more in the locale is because it takes a certain number to make a herd. Two or three wander. In a larger group one may decide to follow another, and anotehr follow the two, until you have several groups acting in a coordinated fashion. It may appear that there is a higher level coordination, when in reality you have several small groups acting independently, randomly. It appears that work is getting done according to some great plan, but in fact it's just the cumulative effect of several random efforts. When you're moving dirt to make a tunnel or cavern, moving it anywhere but in the middle is good.
Regarding how software is written and how languages today are used, it's a factor of the capabilities of the hardware. What machine today can do anything but store, branch, and jump to the next instruction? When that's all your hardware can do, what do you expect from the logic driving the thing?
The writer discusses the workshopping of writers, writers working together, reading and critiquing. When a developer reaches a certain maturity they often go searching for their next mentor. They've learned all they can alone and need the next kernel of insight. They get this from networking, going to SIGs and user groups. They share experiences and techniques, tools and code snippets. I can tell you that many of the neat tricks I've used in my current project aren't mine. They're from the genius on my last project who had hours every night to make neat things in his basement and bring to work in nice packages for the rest of us to build from. If you grow abeyond your 'job' as a developer you can become a member of your developer community. It's empowering.
The writer claims that capitalism nas made it 'literally impossible to teach and develop extraordinary software designers, architects, and builders'. Who is he to judge? How much of the software world has he seen? By what credentials does he make this claim? Has no one heard of 'The Gang of Four'? Does no one know Kernigan and Ritchie? Who are even known by the combination of the first letters of their names (K&R coding style)? I promise you that Melville sat in a quite room quite alone to write his novel. Hemingway as well. And I'm certain they didn't use design patterns or a development methodology for their works. And they certianly didn't work as part of a mob.
Software is a commodity. It is a tool, a conduit, a presentation platform. It is not an extension of your personality poured onto canvas or paper. It's not a monument. It has no greater purpose than its design specification. Only those with an odd sense of need read the OED from cover to cover. Software, like the OED, is a tool. It is a logical conclusion to a defined need, constructed in a deterministic fashion. It's not abstract. It's not open for interpretation.
I hope the birdies keep singing in his world.
- Sig this!
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.
I'd rather be a termite (artisan) than a cog (excessively managed code monkey).
As a termite I don't need any morale boosting management tricks (just nice management which I have here) because I generate my own morale from the way I tackle projects - thankfully I have that freedom.
I could not/will not be a cog.
Software engineering techniques help me as an termite, but I will not let them reduce me to a cog in someone elses management scheme.
blog.sam.liddicott.com
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.
Nope. UNIX\Linux is quite a bit more robust, and the Open Source model can't be beat for addressing hardware problems with software workarounds. Linux is better. Still, not every crash ruled an 'M$ crash'by most people is the fault of M$ code. Often, code isn't the fault at all, but when all you have is a hammer everything looks like a nail. They are just the most popular entity to blame among the under-educated. Sorry to dissapoint you 8^{
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
ESR wrote the same things in "The Cathedral and The Bazaar". They were arguable then, and they are now, for the same reasons.
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
I think you are missing the point. The value in "Mob software" is goes beyond the sum of the mob's man-hours. The society that is created by the mob allows software to not have to be written more than once. It allows the wisdom gained in each of the writings of each of those pieces of software to be shared. It allows small projects to tap those in the mob that have the expertiese rather than spend time aquaireing it on their own (while offering their own expertiese in exchange).
Im not here now... Im out KILLING pepperoni
The main question that I'm left with after reading this article is, "What Motivates the Mob?" They talk about how the "mob" is going to produce all of this wonderful software, but is the mob going to be motivated enough to produce all of the software that society needs.
They claim that 26,000 programmers could write the Space Shuttle software in one year, but how are you going to convince 26,000 programmers to work on such a project? You may be able to convince a few programmers to contribute, but how are you going to convince that many people that they should work on this type of project?
It seems like each member of the programming "mob" is going to gravitate towards working on projects that interest him or her. It would also seem like most programmers would be most likely to work on something that they would actually use themselves. From what I can tell, most "open source" projects start when some programmer(s) says to themselves "I could really use X, so why not write it myself." Then other programmers come along and say "I could really use X, but only if it had Y, so I'll add that piece." And so forth....
Most successful open-source projects seem to be things that a large number of programmers find useful (i.e. Operating Systems, editors, web servers, other software infrastructure, games, etc). Is there enough interest among programmers to write Space Shuttle Control Software? I think not. It would seem like this would either have to be done by some company for money (i.e. Lockheed Martin), or not at all.
If you look on SourceForge, there are hundreds if not thousands of "open source" projects which haven't gotten off the ground because there just isn't the interest in them. The "mob" programming philosophy doesn't seem to be working in this case.
His example about the construction of medieval cathedrals was a successful "mob" project because the people all had a common interest in (or fear of) the divine that motivated them to construct such a structure. There are countless other structures which had to be built by one controlling entity, because the "mob" just wasn't motivated to help out building them.
Finally, let me say that I don't necessary disagree with his premise that "mob" programming can be successful. I think that the success of Linux, et. al. is a strong testament to what the "mob" can do. I just don't think that "mob" programming is going to be the end-all and be-all of programming.
------
www.moneybythenumbers.com
Whenever you hae a large amount of people working on one thing, it tends to turn out average. It's simple math - you have people at both extremes so it ends up in the middle. The more people that work on something, the more compromise has to be made, and anything fringe or revolutionary is cast aside. "Average" means just that ...
THIS would be a perfect example of what I'm taking about. This is a packet sniffer that was worked on by my entire CS class - it sucks. Why? Because too many people had good ideas but no one wanted to implement them. That many people just gravitates towards the plain jane.