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)
Concise post.
Yup we sure do
Steve Wozniak - Apple OS, Games etc (including breakout for Atari)
Bob Metcalfe - Ethernet protocol
Bill Gates (yeah yeah i know - but read your history people) - Altair BASIC (first PC) Altair DOS (ditto) to name but 2
Mitch Kapor - Lotus 123
Gary Kildall - C/PM (first true portable DOS)
Dennis Ritchie - UNIX
John Draper - easy writer (first IBM PC commercially supported word processor)
There are hundreds more
Looks like we just proved that many of you dont bother learning about the very thing whcih you love does'nt it ?
Try reading a few books - may i reccomed Fire IN the Valley by Hildergard/Swaine - the story of the birth of the PC
Giants with the capacity - shit i could give em to you all day - unfortunately this is pre linux... draw your own conclusions on that.
I refuse to argue with Anonymous Cowards - if you want a discussion get an account....
I skimmed through the article, but this didn't make sense: if there are projects that are an order of magnitude or two larger than the space shuttle, and he argues that the space shuttle should have had 26,000 programmers instead of 260, does that mean that these larger projects should have 260,000 to 2.6 million programmers? Where are you going to get that many programmers?
I'll go register the sourceforge project! :)
This would actually be a very cool idea as long as it was kept under control - say restricted to hosts specifically set up to allow it's replication. It could even fight other generations!
They that quote Benjamin Franklin on liberty and safety deserve neither.
Because the commercial model of developing software is itself the problem. You have marketing and sales which promises stuff still in design phase or worse, non existant. Then you set a date and start hammering the code out.
More often than not, you don't meet that date. You can't get all functionalities working the way they were meant to be. But hey, you have a new version number!
So the problem is the "accountability" to the client and the strictly set date by which the project must be ready, nevermind whether it works or has all the features.
A software project will have all the features once the time limit is lifted. Decide what you want, and then do it. The software is ready when all the features have been implemented, regardless of time.
The problem is, this concept of "take your time" won't fit into the commercial model since you have to promise something concrete to the client. So, in order to have some kind of assurance about the quality and time spent on the project, you come up with all kinds of things (processes, methods of thinking, etc.) meant to help the project.
The problem with these is that it's not a process, it's a creative activity. No human is a machine which pumps out a steady stream of lines of code (ugly metric). If you teach all developers your "models" and "processes" and make sure they understand it, I'm sure you have a greater chance of success but my personal opinion is that you should never EVER sell a software project until it's done and you have the final CD in your hand.
For this, you should, in a non-committing way, ask your clients what they want and are willing to pay and then implement those which most seem fit to have. If they need special things fast, then make them fork out the money for it and send a bunch of guerrillas to do the job!
The biological analogy not holding is the entire point of the article! Gabriel is trying to get us to look at a different model where the biological analogies apply.
"Command and control systems are required for synchronized execution of a coherent plan."
Precisely why we need to explore alternatives to the 'coherent plan' model. We need to figure out ways for cooperation rather than command.
Before you argue that we do everything in a command mode, remember that your commanding brain is a committe of several billion neurons working cooperatively.
As to the article, it looks like a quick implementation of the idea would be web sites interacting with others without human intervention. I think this is already happening, such as the search bots from google and friends.
This really needs some quality think time.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
I think someone aleady thought of that...
But seriously, software evolving without direct human control, in a world where everything and anything is connected to the Internet, is a truly chilling prospect. Combine the damage that can be caused by crackers today, the complacency/incompetence of major companies and government organisations that lets them do it, and the ever increasing raw power of hi-tech hardware, and you're painting a very scary picture.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"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?
Am I the only one who thought it was odd that this was written by Ron Goldman. I thought OJ did him in!
Humans were designed by a "mob" process, one with no command and control mechanism. They break down constantly, require enormous amounts of downtime (often unplanned), can't be upgraded, and are extremely expensive and difficult to repair when something goes wrong -- if repair is possible at all.
That's why a car can't juggle.
You could build a juggling mechine very easily, if there were a use for such a thing.
Again, the nature of a tool is that it solves a restricted problem domain very predictably. That's what computer software is for, not to mention houses, cars, hammers, and so forth. Biological systems have different requirements, to live long enough to reproduce in a variable environment. The design methodologies for the two sets of requirements are different.
Tim
Um...people aren't ants.
And discovering similarities between a software-development "ecosystem" and the "real" ecosystem, while it might give us at least a few useful insights based on our current understanding of natural selection, doesn't mean the software-development ecosystem is sufficiently like the real one to make a numbers game an adequate substitute for proper design.
I believe there's a lot that's true about the "mob software" paper, but even if a lot of the stuff that's hand-waved ("minor" problems like, how do we annotate modules with cultural information in a way that's useful to both the computing infrastructure and the human beings?) is solved down the road, the only true ecosystem will remain the one we already have.
The "mob software" ecosystem will therefore suffer from a phenomenon that every free-software project has had to deal with, but which is not generally a problem for the "real" ecosystem:
For this reason, I've tended to find appeals to the "if I build it, they will come" approach to explaining why sound engineering principles are rejected out-of-hand by "those in charge" of certain OSS projects to be unpersuasive. Yes, "they" might indeed come, but if "they" are incompetent at the task at hand, and, having spent several years making "contributions" that direct the project even further down a technological cul-de-sac, become sufficiently competent to recognize what's been going on, having not convinced the "leadership" -- those who say "but we've always done it that way, it works", a kind of thought that's even harder to challenge in a mob-software approach than in a proprietary-software shop (and I've tried both, believe me) -- they are not only free to leave, but they take the most important part of the investment that little ecosystem made in them: their newfound competence at the task.
At least, in the real ecosystem, when a creature "leaves" (by dying), its nutrients are reabsorbed, over a period of time, back into the living mass. (Yes, the creature's knowledge and experiences "die", but they aren't as critical an "investment" for the ecosystem, which doesn't really, in any way, "care" about that creature.)
A mob-software ecosystem will, by the definition given, depend highly on the experience and expertise of individuals, even if only collectively, so it will need a certain degree of engineering "oversight" (and this is what the author probably means to say in a few places).
The closest equivalent to that in the "ant world" might be the genetic programming. We're not ants, so we don't have the genetic programming to cooperate like they do, and we don't yet know how to build an (abstract) organic ecosystem (say, a computing network) that serves as an adequate substitute.
But the promise is there (I've certainly been thinking along the same lines for, well, over two decades), it's exciting. And while I might raise an eyebrow over the apparent bashing of capitalism (preferring if the author had more tightly focused on the raising of intellectual privilege from a society-based concept to a right-to-profit monstrosity), since I'm not prepared to agree with the notion that a gift economy can't flourish within a society that, like the USA, permits capitalism as well (after all, we do have both, however imperfect they might be, and, unlike most experiments in command-and-control economies, we haven't executed millions of innocent people in this century to impose our new utopian structure on the population), all I can think to say after reading the paper is:
Practice random senselessness and act kind of beautiful.
It was a joke, get over it...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
As to the article, it looks like a quick implementation of the idea would be web sites interacting with others without human intervention.
Whee... Code Red!
Not to mention the ideas of 'antibody' viruses (legal implications aside, it's an interesting idea)..
Delphis
``"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.
I'm done reading slashdot comments. The posts regarding this topic by people who obviously didn't even bother to read the paper are indicative of the quality of the majority of the slashdot posts.
Really? I'd like a human level Artificial Intelligence please, with a user interface that customizes itself to whatever class of user interacts with it.
You can pick any 5 people you want.
When should I expect delivery?
(try never, blowhard).
Here's a spoof story on so-called hacking methodologies.
Okay okay, I know it isn't totally on-topic but it's worth a read anyway...
Programming with a dose of satire: http://www.SoftwareReality.com
This article is full of trash. I read incredulously until I saw the word "duende" and at that point I could not endure it any longer.
We need practical solutions, not philosophical soliloquies.
Small teams, if not individuals, write the best software, hands down.
That's the whole idea of mob software: by using large numbers of programmers, you can afford to kill off the ones who don't fit in with the others' desires, leading to a 'survival of the ideas thought up by the group with the largest numbers and best weapons'! I, for one, would start by removing that damn one-post-per-two-minutes limit on slashdot with my mob...
They that quote Benjamin Franklin on liberty and safety deserve neither.
http://www.nutters.org/monkeys.html
Interesting reading.
Yeah, except that sometimes people want to do things differently and then expertise is split. Witness: Gnome/KDE, vi/Emacs :-), Linux/Hurd, etc.
Work is duplicated all the time.
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.
slashdot is not run by the mod
Its run by a religious organisation - the first national church of linux - its easy to work out - the follwoing are displayed
-Intolerance
-Race Hatred (MS users)
-Inflexibility
-Anyone who doesnt agree is obviously wrong
-All those who dont accept the one true OS are going to hell (or Redmond - same thing in their eyes)
-They have all the knowledge and the wisdom in the world
-Clinging to outdated theories and concepts in the face of evidence which disproves them
unless...
Bored immorts and the "switch" command. Need I say more? Probably! But I won't.
the nature of a tool is that it solves a restricted problem domain very predictably.
The problem is that the relevant problem domain refuses to stay so restricted. Each answer grows three new questions.
Hey, didn't Bill Gates once claim that nobody would ever need more than 640MB of genetic information?
Practice random senselessness and act kind of beautiful.
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!
"I can't imagine anyone being willing to buy a house that had been built with no architect, no blueprint and no foreman -- a house built by a bunch of construction workers doing whatever they thought was best that day, and not bothering to write down any of their decisions."
You've just described how the overwhelming majority of homes lived in by human beings throughout human history have been built. The first world ethno-centrism of the slashdot crowd would be funny if it weren't so pathetic.
Fact is, most of the world's people are non-literate, so they couldn't "write down their decisions" if they wanted to. They build homes based on a common vision which they acquire by growing up inside the culture. Skilled craftspeople (carpenters, brick layers, etc.) do what they know how to do, and a finished and quite livable home comes together.
Interestingly, many of these homes are superior to modern architect designed houses, for example in seismic stability (i.e., they are less likely to collapse in an earthquake). Why, because they embody the collective wisdom and experience of generations of builders who know the local conditions implicitly. That which has failed in the past has been culled, that which stands for decades is copied. No rigid formalism is imposed on either the materials or the landscape.
To build software like this means:
1. We must be able to share our sucesses and what we have learned from our failures. This means open source.
2. We must build software in a context in which the users can write the software. This mean new tools that enable non-technical people to write useful code.
3. We must build software that can be joined with other useful software with minimal effort. This means software that is reflexive - it knows what it consists of and can tell other software, so that they can merge.
"Don Cox, Don Perens requires your presense at..."
---
"Of course, that's just my opinion. I could be wrong." --Dennis Miller
I'm confused.
Is it the Sicilians or the Yakuza?
And for the automatic transmission guy, he should step out of the North America once in a while. The rest of the planet uses a clutch. It ain't fun to drive unless you have one foot less than the number of pedals.
J:P
--- Worst tagline ever.
When I read this headline, all I could picture was a bunch of mobster software developers sitting around a table like in Goodfellas...
Joe Pesci: "Funny how? I mean, funny like I'm a closed source developer? I amuse you? I make you laugh? I'm here to fuckin' amuse you? How da' fuck am I funny? What da' fuck is so funny about me? Tell me, tell me what's funny."
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
next on /., an essay where several renowned musicians are quoted supporting a "flowering carnation" development model. This development model is powerful and interesting for several reasons, as Britney Spears, members of the band Metallica, and popular rap artist Eminem point out to us.
Thanks for making the blindingly obvious joke we all thought of the moment we saw the headline.
If the beaver offers you a upgrade... You take the upgrade.
CmdrTaco: We gonna take Gates' balls n stuff em down 'is TROAT!
Get your "Whack Adobe" Tshirts @ thinkgeek!
Ask Slashdot: How can I become a bookie?
Katz would write a four part series about Vinny's vegas casino
- = Maskirovka
Anything worth coding is worth coding for money.
Microsoft proverb
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.
Actually, one of the things that made Apollo much more successful than the shuttle (even though it wasn't 'reusable' its cost to launch a pound of payload to orbit was orders of magnitude less than the shuttle) was that they DID "throw away" a number of rockets as they refined their designs. Essentially, every launch improved the skills of the rocket designers.
I'm still reading the somewhat lengthy article (on paper of course, can't read that much on screen)... But has anyone noticed the three rules the authors give for swarms? They're exactly the same as the three rules for flocking boids...
...within the very limited problem domains and development paradigms used so far in the short time we've been doing this.
The Mythical Man-Month is a good read. But it predates the widespread use of personal computers and the net.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Well, as long as everyone else thinks we should be "mob programming", I guess I should too... :)
"Your superior intellect is no match for our puny weapons!"
I guess this means that you are part of the "get-the-torches dept." that produced this news article... ;o)
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
People can work on internet infrastructure because they can treat all of the other devices as following the same set of rules with variation in the details. Everything is constructed such that the large-scale behavior is obvious from the rules that all of the devices have agreed to follow.
The Mob Software idea would have packets routed somewhat randomly at each router, with that router deciding, without relying on system-wide uniformity, where to send the data next. It's possible that this would work, but it would certainly lead to a much greater variation in latencies and dropped packets.
the best way to kill a project, mire it in personal squabbles whenever someone's precious idea is thrown out in favour of another.
never underestimate the power of stupid people in large groups... or was that never underestimate the stupidity of large groups in power...
*I need coffee*
anyways, you pool enough people, you'll end up with a lot more stupidity... but it does depend on the people, what they are trying to achieve and why they are working together...
think the Beatles, not the Spice Girls...
Christopher Alexander, like most architects, is a great pretender. If you want to buy a good architecture book, buy one with lots of pictures. Not one with any words. At least not words written by an architect; unless you have the stomach for some of the most god-awful prose on the planet. Now Alexander isn't so pretentious and unfathomable as most. In fact, he's a refreshing counterpoint to most of his contemporaries: he simply illustrates the obvious with fetching little doodles. But to look to an architect for guidance on how to build software! For shame. Architecture, as a profession, has sunk so low it's a disgrace. I'm embarrased to say I've ever had anything to do with the profession. So I won't.
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.
Isn't he one of the guys that OJ slashed?
dinner: it's what's for beer
For one thing, he points out that there is no distinction between the cathedral and the bazaar: both are build using the same principles, many individuals that produce something in an uncontrolled, unorded, unpredictable way.
It is indeed *an* Open-Source development model, it's a bit more radical than the popular one though.
Mr. Gates never asks a second favor once he's refused the first, understood?
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!"
After reading this article and the "What if what once was scarce is now abundant?" quote, it made me wonder how the world's governments are really going to treat the open source community.
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.
I was surprised and pleased to see references to Stuart Koffman in this essay.
The research being done at the Sante Fe Institute with regards to complex adaptive systems, and the nature of complexity in general provide a number of insights to coders writing large software projects (and many other discplines...)
I would highly reccomend At Home in the Universe as a good introduction to the ideas behind research in CAS. ISBN: 0195111303
For those who like more thorough and academic texts the S.I. produces a number of conference and workshop transcripts which are chock full of great papers and enlightening discussion. ISBN: 0201626063 is a good one.
As software/hardware systems grow ever more complex, we will need to apply ever more powerfull methods to manage this complexity. Perhaps by learning from the experiences of millions of years of evolutionary biological computation to socio/economic progression and interaction we can begin to fashion methods of building software/hardware that can adapt and scale in ways we dream of...
Maybe the next one will be funny.
--Moss
This is a
Now there are two of them.
There are two _____.
Hollywood, Television, has become the dream machine. We need to take that back; each of us is a Dream Machine
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
Yeah OK so the guy has serious creds at a code level but that doesn't mean he's automatically right, nor original. I am so tired of these hax0r artise / code poet essays on /.; when will it end?
/. is read by vocal code poets and a horde of lurking team developers. I see the team developers speak up every now and then.
:) j/k
In my experience you can categorize programmers into the following three groups: lone rangers, uninspired key pushers, and team developers. Lone rangers can be extremely productive on their own and know it, but don't know how to split up work, resolve disagreements, and make sure the important dirty work gets done. The uninspired key pushers are the ones who prove the axiom that a great programmer can be 10x as productive as a bad one. They're the ones who write spaghetti code, use code generating wizards and don't understand how the environment they're programming for works. Finally there are team developers, who may not be as productive alone as a lone ranger but who can actually break up work, debate ideas rather than descending into ad hominem pissing matches, and who get all the work done (not just the fun stuff). I suspect that
The idea of mob development is not original, but I argue that it's not limited to open source either. You don't have to be an aeronautical engineer to know that a rocket shouldn't blow up on the launch pad. Likewise, commercial software gets pushed on users who definitely have plenty of eyeballs capable of testing software. The sad part is that they pay for the privilege, where in open source at least the helpful eyeballs don't have to pay. Open source has the advantage of allowing outside developers to fix problems, but it's not as though commercial software customers don't notice bugs because they don't have the source.
I strongly disagree with the author in a couple of cases.
The cathedral analogy is completely bogus. This is ESR's fault, and it's a logical fallacy that code poets often use to "prove" that open source code poetry is the One True Path. Cathedrals have very basic requirements compared to a piece of software, and involve designs which were centuries old at the time. Hire an amazing artist to do some art for the cover of your software manuals, retail box, splash screen, etc. Wow, what an incredibly clever development process you've discovered, he didn't introduce any bugs into the product! The glue used to bind the manual smells nice, because you hired a fragrance designer? You are a software development guru now, because that person didn't get in the way of the code being developed. What?? It doesn't make sense because these are very distinct concepts, easy to modularize. To get a realistic comparison, try getting 40 sculptors to work together on the front door, another 20 on the tympanum above the door, 10 on the side door tympanums, and make sure they all coordinate their efforts so everything looks consistent and follows a unifying theme. Now you see how the analogy breaks down.
Gargoyles, stained glass windows, pulpits, they're just ornate versions of everyday objects that everybody already understands. In techie terms, I'm saying is that a Cathedral is not only a highly modularizable design, but that the interfaces between modules are minimal, and that the overall design is obvious and familiar to all involved. Software generally isn't like that, particularly large software. It's unfamiliar; it's not something you can touch; the requirements are poorly understood / shifting / disagreed upon by stakeholders. This is why the popular CS ideas are the ones that favor a design that changes during the implementation phase(s). The rocketry analogy is much better - in that case it was something unfamiliar and huge. Fortunately you can touch a rocket, and pretty much everybody wanted to put a small object in orbit. Compared to software, rocket science is easy
Also, the biological analogy is bogus. Those little critters are running some seriously mature software (tested for more than 20 years, I assure you) that I dare not estimate in terms of lines of code. I don't think we have billions of years to get our software right via genetic algorithms. We have to play creator and move things along faster than they would on their own.
Yes there are a number of *nixen out there, but considering just the free ones, I doubt there is much reinventing of the wheel since most of it comes from the same GNU sources, compiled for each kernel.
Finally, the author disparages computers based on stuffy old math inspired languages such as Fortran and C, and then goes on to laud a series of open source projects (as proof that the mob approach works in small sizes, meaning just a few million developers I guess) which are all written in... C.
Nah, it's...
"Something unfortunate might happen to your system if you don't pay monthly for upgrades."
Well, at least it's not a duplicate (yet...)
Je t'aime Stéphanie
But the really frightening part was the vision of Linus waking up to find that Bill left a penguin head in his bed.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Me neither, but if someone offered it to me, I'd live there. Same way many of us live in cities built by disorganized multitudes. The essay's about creating gifts, not commodities.
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.
... then nothing will do.
I would be the first to offer time and effort for such a system. Just imagine, contribute to put somebody in space and bring him back safely. Now, that would be something.....
IANAL but write like a drunk one.
Read my keyboard review.
Software should be written while you smoke a big fatty.
--Lawrence Lessig for Congress!
As long as you have some organization, it will work, though. Er, Linux?
/Brian
Uhh.. he specifically said that Linux and Open Source t is *not* mob software. For the specific reasons you mention.
If you read the entire article, mob software really doesn't exist yet.
Or, maybe the reason mob software doesn't exist is that humans behave in certain ways when they are mobs, as opposed to gangs. And those ways just happen to not be conducive to creating software.
Besides, how do you know it doesn't exist? After all, the Cosa Nostra likes to keep it quiet, and those who rat on it have a little accident.
--- Will in Seattle - What are you doing to fight the War?
Do we really need another organized crime syndicate in the software business?
After all, we've already got Microsoft.
Yeah - orgy software, that's what it is anyway. Or maybe software developed on a 'love swing' or a BDSM rack.
Grovel before the Mistress of Macro, the Princess of Perl, the Dominatrix of Data! Lick my boot, slave.
Hail, fellow computer-hacking, karate-kicking, poetry-writing, guitar-playing Zen Pagan Taoist Atheist Discordian, and all hail Eris!
Oh, OK, so I don't yet do Karate 8^}
On a more serious note (pun intended)
And as a side, but directly related note - many computer crashes are really hardware problems. It's just easier to blame lines of code you can (sometimes) see than to remember that there are millions of lines of VHDL and billionsof logic gates and that hardware breaks from time to time. Sometimes it's by bad design, and sometimes parts just break. Next time windows reports a GPF try changing your RAM SIMMS (or what have you)
Cheers!
Zero__Kelvin
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Because absolutely *everyone* here has either:
1) thought of the obvious Mafia jokes, or
2) bitched about how obvious the Mafia joke is and how it shouldn't be considered funny,
allow me, while ostensibly making a 'mob' joke, to bring a new and fresh topic of conversation to the table:
Who would win in a fight?
a) Don Corleone (young or old; your choice)
b) Don Juan
c) Don Quixote
d) Don Ho
e) Don Adams
f) Don Diego de la Vega
g) Don Knotts
h) Don Pablo
i) Donatello (artist)
j) Donatello (ninja turtle)
k) Don CowboyNeal
Three Step Plan:
1. Take over the world.
2. Get a lot of cookies.
3. Eat the cookies.
"A concise submitter, how refreshing."
1: Hey Louie. I think he's calling us names. You think he's calling us names?
2: 'Think so.
1: Yea, that's what I thought.
Shots are fired, someone screams.
The Mob Effect Can Take Over, and Unexpected Plenitudes Ripen
Riiight! Good stuff comes from having a lot of developers?! Get real. I mean, look at Linux.
If linux were beer, it would be shipped in open barrels, so that everyone could piss in it.
Also, your example has a few flaws. First, because the project was (probably?) a piece of required coursework, you don't get the same level of dedication that you get from someone who works on something just because they want to.
I think this is one of the best things I've seen posted to Slashdot yet, and I've been a regular user for.. four years? three?
The possibilities have rekindled my sense of why I began programming in the first place (Because it's FUN!), which a day-in, day-out daily grind at a dot-bomb has slowly eroded.
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
I am looking but i still dont see the 'it thought MS were the mafia post' yet.
:)
Still and all it has to be coming soon
I refuse to argue with Anonymous Cowards - if you want a discussion get an account....
I always thought that the bigger the project, the fewer people should work on it...
This statement is a common misreading of Brook's The Mythical Man-Month. He writes:
The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance.
Brooks then goes on to suggest ways of organizing and managing large teams. He writes in the supplemental chapter to the 2nd edition:
If one believes, as I have argued at many places in this book, that creativity comes from individuals and not from structures or processes, then a central question facing the software manager is how to design structure and process so as to enhance, rather than inhibit creativity and initiative.
He then quotes E.F. Shumacher:
The Principle of Subsidiary Function teaches us that the centre will gain in authority and effectivenes if the freedom and responsibility of the lower formations are carefully preserved, with the result that the organization as a whole will be "happier and more prosperous."
Brook's analysis appears to supplement or anticipate the problem that Gabriel & Goldman are trying to solve.
You think I'm funny? You think I'm a frickin Code Clown huh?
ESR wrote the same things in "The Cathedral and The Bazaar". They were arguable then, and they are now, for the same reasons.
I have a day job. I also work on Free software, and other things related to open sytems (e.g. standards for things, not "Open Source").
I also have plural shiny things. This is because my achievements _outside_ may day job have two effects:
- I gain useful skills that eventually get used in my day job. I become the foobar guru.
- I can point to my achievements outside the day job and say "look! See, I am of consequence elsewhere; I understand the industry well, have a little influence in it, and another employer would jump at the chance to employ me".
Actually, the problem is, no time to play with the shiny things because I'm too busy hacking interesting code. Interesting code is a real breath of fresh air because you do it when you want to, and not today if you don't feel like it.Yes, but no.
It's really the "million monkeys pounding on a million typewriters for a million years" theory, enhanced with a darwinistic survival-of-the-fittest feedback loop.
The writer may not have intended it that way, but that's really what he's advocating:
"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.
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
(They're all quotes from The Little Man From Another Place. You know, the "This is a formica table. Green is its color" guy.)
Dennis Ritchie didn't concieve and build UNIX all on his own. Read your books again. And the others are laughable as "Brooklyn Bridges". More like the first bamboo bridges, built with considerable ingenuity, but irrelevant in the modern context other than for pointless hero worship.
the coding would be great.
if
horse.head <> in bed
endeavour.to place.head in bed
else
job.done
endif
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.
Isn't there? There is two large mobs, not guided by any clearly defined leaders. The hackers and the users. The hackers basic rules are: 1. Improve anything that can be improved 2. Support free-flow of information 3. Seek out what's needed and add it 4. Publish all knowledge The users have got two goals: 1. Communicate 2. Seek out the information wanted The users will always seek towards the services that attract them, making certain 'piles of sugar.' The hackers will communicate, together decide on what's important and develope the net. Within these mobs there are gangs (e.g. /., linux communities) leaded by certain people, but no gangs or people are important for the overall rules and evolvement of the net.
I realise that software companies play a role here, but no more than commercialicing the mob products, and helping in the development. They then follow the rule: Make the things that will pay off and become 'sugar piles.'
Look a monkey!
"IF YOU HAD 20 SPACE SHUTTLES TO THROW AWAY IN SPECTACULAR FIREBALLS BEFORE IT WAS FINISHED. "
Gabriel's point is that NASA did just exactly that; scores or rockets blew up in spectacular and sometimes lethal ways. Each of these disasters contibuted to NASA's accumulated knowlege of how to send people into space.
Even the Challenger disaster was part of this process - those people died and the shuttle was lost so that NASA could learn that O-rings fail in low ambient temperature situations.
You more or less totally missed the point of the article. The fact is, that whether you like it or not, Space Shuttles blowing up is an inevitable part of _great_ engineering feats. So also, catastrophic failures will be part of _great_ software development.
So, the only way to make truly _great_ software, is to not try to guard against the inevitable catasrophic failures by using some overly rigid "methodolgy." Instead, trust to the only proven method for great collective efforts - let lots of people with a common vision, sharing what they've learned along the way, hack at it. Note that I did not say "hack at it until it's done," because, really, it is never done.
Holy crap, I got sucked in and held out until about 8/10 of the way through the article to finally discover what the hell he was talking about.
;) Who cares? Well this guy seems to want us to believe that if we just throw all our "gifts" into one big humongous happy amorphous blob, that we will instantly be able to miraculously combine any pieces and come up with amazing software. Does anybody know an author who writes books solely by going to every library in the world, examining every book, and copying the "best" parts? My point is that even if we threw all this marvelous stuff together and gave access to everybody --** there would be no possible way for a single human to digest such vast amounts of information **--. It would be like creating the best bottled water by sorting through every h20 molecule in the world. Impossible.
My rebuttal: Mobs are stupid.
Human intelligence does not work like digital information. It is not strictly cumulative. 6 billion people as a whole do not exhibit intelligence 6 billion times greater than the individual person. In fact, one might say that collective intelligence even *decreases* as more members are added
Furthermore, let's say this is magically possible, and that it actually results in lots of great software. As he mentioned, the gift economy is still a subeconomy in the "commodity" economy. That is, we still rely on things from the commodity economy to survive. Do you know any authors that maintain existence solely from reading other published works? So unless we come up with a way to allow non-coders to send non-digital objects (like, say fruit baskets, or baked hams) into this amorphous collection, simply working all day on software will not result in breakfeast, lunch, and dinner being downloaded from your email account, and popping out of your CD-ROM tray.
The limiting factor of software development is the capacity of the brains of individual humans. Neither putting all the software in the world together, nor putting all the brains in the world together, will solve this problem.
It's 10 PM. Do you know if you're un-American?
in my vision the power of Open Source is that people can do what they like to do. And there is no penalty for doing it your way. Whilst coding, documenting etc. for a living means do the it the way your boss wants it to.
In the referenced timeperiod of building cathedrals large construction firms simply did not exists so in general everyone was hired and treated as a qualified individual who was supposed to know how to do his job.
So it was a low level organisation but absolutely not a mob.
And if you don't believe me, I'll send over the Reguzzo brothers to take you fishing. Listen to REAL Mob radio at: wmob.com Very truly yours, Woot_spork
evolvement?
evolvement ????
you, sir, are suffering from an over-enbiggened vocabulary.
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
So I guess Microsoft OS's must just use the hardware a lot more than Unix then?
i was discussing religion with a relative the other day
following that discussion i had a thought:
the idea of a big ol' God is just one of the termite arches they mention in the essay
humans are termites, in a way
we are all built out of the same stuff - the DNA and the collective upbringing of our young, generation after generation, in a society built out of the same kind of units the young are supposed to become one day themselves
so there's this uniformity spanning all of it
i'm not surprised the folks back in the day thought there was something larger controlling all of it: it's there allright. but it's not controlling anything per se, it just makes things happen that are more likeley to happen than other things
people get angry over territory, they take pride in accomplishing something, they develop and act on feelings inside each unit
so if you tack a name onto this thing
you have god.
you have an arch.
you have something very, very large.
now the question is: is it any good? is it valid for some purpose or other? do we need it? do we need a God program?
i don't think so.
i also read Richard Feynman's "Cargo Cult Science" paper someone posted a link to here
if my theory on how the idea of religion came into existence to begin with (partly) is true - we got it all wrong. god isn't something that is controlling anything - it's merely an image of a certain bearded man who was a celebrity 2000 years ago you might happen to see if you were to look down at a city from high above and squint your eyes, or on a tortilla or as a rust spot
so what might happen if this mob software theory would actually be *performed*, we could get a gargantuan something that could possibly pass for something useful if we'd squint our eyes all together now.
but:
another thing might also happen.
have any of you actually read a byproduct of this phenomenon i talk about earlier: the bible?
i think most of you will agree that it is a spectacular piece of literature.
a child of its time, indeed, but i think the Bible will be a hell of a better read in two thousand years than listening to Wham songs will be - a recent example of a child of its time.
how was the bible created?
by a mob.
a mob who had the motivation, the general goal.
to create a work of praise, to create a compilation of guidelines, laws and explanations to those guidelines and laws, to build something that would last and be good.
to make the mob model work, you wouldn't try to create a god.
you'd write a bible.
i'm not sure all of these ideas are coming out correctly
my english is getting a little slippery - it's 4:36 in the morning and i wouldn't be surprised if this got rejected because of the sheer length of it.
but i started thinking. and that's always good.
>what was it I (and hundreds of thousands of other) IBMers used for, like, 20 years?
You used a grab-bag of renamed office productivity apps that had almost nothing to do with Guglielmo's massive boondoggle. Office Vision was *supposed* to be an integration framework for apps to run identically across the mainframe, mini and PC product lines. It didn't happen.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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
You think current development methodologies work well?
I want you to remember that statement the next time your machine crashes. The next time you get an e-mail containing a virus. The next time you can't get to a website because the server's down.
Go read the RISKS forum. Then tell me that current software methodologies work.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
What an amazing essay. I think a lot of his points are very valid. He worries about how programmers and designers today are going to learn from the mistakes of their elders if the source code is not available for them to see. He also worries that as the size and complexity of systems rise, we are going to get Towers of Babel instead of cathedrals.
I think the main disagreement I have is that programming is STILL a very nascent art form. He talks of centuries of cathedral builders all sharing the same design language and not needing a top-down design. But it took church builders *centuries* to develop those languages. How many attempted cathedrals collapsed under their own weight? How many people were killed building them?
In programming, we are still learning how to bake adobe bricks and he wants to talk about cathedrals. We can buy as much RAM as existed in the world in 1965 for $19.00 today, and we can fill up that RAM. But what about in 2035 when $19 will buy you today's world full of RAM?
We are making progress though. First it was binary switches, then hex codes, then ASM, then modular programming, structured programming, object-oriented, component-based, service-based. We are developing a common vocabulary of things like Design Patterns which programmers can use to communicate architecture decisions in 1/100th of the time. There is probably 1000 times the raw amount of source code in the public domain now as there was in the 70's.
I agree with his overall points, but I think we have a tendency to compare ourselves too early to the cathedral builders when we are still figuring out how to bake bricks. We are still in the equivalent of the 1200's, not the 1600's. Let's be patient, and see what the software designers 200 or 400 years from now come up with. I bet it makes us feel like cavemen.
Crash
"The difference between theory and practice is small in theory and large in practice..."
All the "attempting to be funny" posts. Look at yourselves people! you have NO lives!
... 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!
It isn't clear what solutions the authors seem to propose other than a vague concept of needing yet more people on even larger teams vaguely flailing away at a broad problem (such as "Go build a cathedral"). There are several clear reasons why such a methodology is flawed, and why the path they took to reach this conclusion is flawed (although the poetry they weave to reach it is refreshing?). 1) Yes, software does "grow." The authors fail to acknowledge "The Mythical Man Month" by Fred Brooks on this issue though. In fact, the authors borrow concepts from Brooks throughout, but come to much weaker conclusions. The fact that software (big and small) is an evolutionary process is one of the reasons why this "get a big ol' mob together and get it out the door" mentality fails. 2) The authors seem to reach a much different conclusion from Christopher Alexander than (I feel) most would. The "mob" surrounding the cathedral builder is a small, highly specialized, and tightly coordinated team. Try "The Wealth of Nations" by Adam Smith for more on the concept of specialization. One of the reasons the space shuttle software is as good as it is due to this aspect of specialization. Likewise, there may be a "mob" doing the physical labour of building the cathedral, but the builders guiding the design are extremely focused. Here again, take a cue from Fred Brooks - big teams yield big messes. As we look through computing history, smaller teams have been at the center of many (I would say "most of the important and successful") bug-free technological developments. On the other hand, large team software products are frequently a mess. 3) What do the authors think "big" software projects are? They seem to think that mission-critical projects like the space shuttle fail to constitute "big" projects, as do many- (maybe millions?) line programs with millions of users (such as MS Office products) also fail this "big" distinction. What do they want? If we as a software development community can imagine it, we generally get around to building it (even though it sometime takes years to get there...). So, what "big" project do they feel we are lacking? 4) At several places the authors mention various failed rockets, seeming to suggest that failure is bad and that by using their mob methodology that those failures could have been avoided. Doubtful. Why? Behind the vast majority of software (or any engineering project...) there is a history that leads to the successful project. Hershey went bankrupt _how many_ times before making it big with chocolate. How many people crashed before Lindberg made it across the Atlantic? Same concept is at play here...you test, learn from history, build prototypes, etc., and eventually you get there. Along the way you refine methodology and practices, but just throwing people (the "mob"), money, bureaucracy, etc. at the problem seldom proves to be the successful answer. 5) Another problem was along the lines of the "gee if we only had 26,000,000,000,000 more people working on this project...." There is a huge difference in the productivity of a "good" programmer versus an "average" programmer.
...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!"
Paper Phones
Posted by michael on Friday March 09, @11:51AM
from the dog-ate-my-phone dept.
Fuzzy_Damnit! writes: "Whoa! Paper phone!"
Link is here. Seems eerily familiar... I sense a conspiracy!
Cheers,
levine
Somehow, I don't remember the CircleMUD code having sentient neural-nets coded into the Mob routines.
Even the best elven scribes would be out of their league with this one.
the liberator who destroyed my property has realigned my perception
www.quantumheresy.com
Don't forget the title!
For those at OOPSLA 2000, what were your thougts?
I will say that the presentation was rather interesting.
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
Fubar is an acronym. It stands for Fscked Up Beyond All Recognition.
It is not spelled foobar, no matter how many programming texts say otherwise.
Come on, man - take pride in profanity!
Wow, this suddenly puts the new (2.9) OpenBSD art into better perspective.
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
It's kind of neat, actually. The smarter secretaries and managers can write small programs in Excel or Visual Basic that do needed work. To a considerable extent, Microsoft owes its success to this. Microsoft Office sells on its own merits, unlike Windows and IE.
Dennis ritchie didnt thats true - but he built about 90% himself - and thats in the books No one said they were relevant in current context - they really arent (including Dennis Ritchie) - i was illustrating a point that the people are there and will continue to be there now and in the future - its hard to been seen as the sole creator of anything these days but the geniuses do exist. As for pointless heor worship - history will teach us many things - pity most people dont want to know.
I refuse to argue with Anonymous Cowards - if you want a discussion get an account....
For a real thrill I give you "Mob bridge building" and the evermore exciting "Mob-built bridge mob testing"...
HA!
Wherefore are those giants that had the capacity to conceive, engineer and build such monuments to non-mob engineering as the Brooklyn Bridge? We sure lack them in software!
Sharing of knowledge should be optional but highly recommended.
Look a monkey!
What if what once was scarce is now abundant?
Actually, that was Bill Gates's motivation. The scarce factor was computer hardware power. Specifically, Gates asked the question: what would software look like if hardware were free? The result is the now-famous prediction that every desktop in every home and every office would have a computer ... and the now-infamous goal that every one of those computer would run Microsoft software.
I believe that open source is more motivated by this question:
What if I schedule my own activity as a programmer, rather than have someone else schedule it for me?
This is literally and deeply self-organizing. Many open source projects have a distinct lack of mandates. People do what they want. At most, if an open source project leader wants some bugs fixed, they announce that they are rejecting all contributions that are not bug fixes. But they don't reach out to people and say "here, you fix this bug."
This self-scheduling behavior works astonishingly well. This leads me to believe: the purpose of the management structure in a software company is not to organize the work of the company. The workers in a good company actually organize their own work anyways, and managing them is like herding cats. Instead the purpose of the management structure is to deal with the users of the software; specifically to turn them into customers and extract money from them.
If users of software would volunteer to pay for the software themselves, we could dispense with most of the corporate structure. That's what shareware was all about. But users won't do that on their own, and that's why shareware failed.
Keep in mind that the data regarding whether a piece of software is "quality", as well as the data regarding where to find such software, are themselves forms of software, as far as these illustrations go
Yes. And individuals decide which peices of software they like, and hence which they use and contribute too. Nobody *has* to find the perfect piece of software- they just find one they they like for themselves. Then they customize it, or redesign it a bit. Then they share. (now iterate)
If there is no project matching what they want- they might start one on their own.
And, remember, our monkeys will, unlike the ones in the thought-experiment, tend to follow the "monkey see monkey do" approach, by and large -- meaning if a few "leader monkeys" start down a technological cul-de-sac, most of the rest will follow, all proclaiming the "quality" of the work they're doing.
Actually, hobbyist programmers are pretty fast to abandon a sinking ship, as soon as they see a better one. Of course some stay behind- but overall they are a fickle lot.
What you are describing as the missing element- oversight- is in fact the Free software movements greatest strength- not its weakness.
What you percieve as "leaders" of this "community" are actually quite ephemeral. Their technical decisions are constantly challenged by others- and for every major endeavor there is almost always a competing one with a different philosophy.
An individual's choice of what is right for him always trumps a dictator or commitee's choice of what is right for everybody.
Bottom line:
1) Fad is a terrible word for a software methodology. It doesn't even come close to fitting.
2) The whole premise of the article is that the current system(s) in place don't work well. This is just plain false.
Need I say more?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Almost all the source code for this massive system--estimated in the billions of lines of code--is available under a license that grants total recombination rights: Any fragment of source code can be used for any purpose.
Companies dip into this pool to collect pieces and parts to build custom software for their own use. Doing this reduces their development costs to a fraction of what they once were. Following the precepts of xenia, these companies, for the most part, return their custom code to the pool. Other companies dip into this pool to create niche software; they augment their businesses by supporting this software and helping their clients.
I was surprised to see this go unmentioned.
For just a split second, I was hopeful that it was talking about BYOND, a fabulous game development environment. (in their language, the standard "player" object is called a mob) Oh well. Interesting read, though.
Say hello to zMac.
...was too big for Notepad to open when I viewed source on it. One of my little rules of thumb is that a web page should never get that big. I lost interest about half way through it. You can call me an LD'd short-attention span impatient kind of guy if you like, but there is something to be said for being concise and to the point. In other words, cut to the chase! Everybody remembered Lincoln's Gettysburg address. Nobody remembered the guy who spoke for two hours before Lincoln.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
Blue Screen of Death, meet the Kiss of Death.
If this software model involves "hundreds of millions of programmers" essentially producing whatever they want why have humans producing the "parts" and customizations at all?
Would it be possible to have thousands of computers that are producing random "parts" of code and another group of thousands of computers taking those "parts" and combining them to have new customized "parts" and so forth until coding becomes only requesting this huge network of computers of a program with some functionality and letting it try to combine all of these "parts" of code until its requirements are met?
Kind of like the million monkeys writing for a million years except hopefully it doesn't take a million years.
This comment was generated by a Squadron of Ultra Ninjas
I would dare to guess that the writer of this article is quite likely to be an INFP personality according to the Myers-Briggs personality type classification system.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
"I will give you a patch you cannot refuse"
Well, it might work
/Janne
Trust the Computer. The Computer is your friend.
I agree with much of what he says in "Mob Software," but I think I'm ultimately dissatisfied with the essay, and I don't think it's my lack of understanding.
I can summarize the key points as follows (though everyone should read the actual essay, not just the Slashdot discussion, not even mine), with which I violently agree:
- No one knows how to reliably produce quality software on schedule. We've learned a few things that work pretty often, and more things that work sometimes; but our efforts are failures more often than those of bridge builders two thousand years ago, or a roulette player any time. We don't get it.
- Sometimes "mob software development" works. (Examples cited.)
Sure; but sometimes, anything works. There is no method, no process, no trick so lame it can prevent any and all projects from succeeding. Some projects using UML as a Holy Grail and succeed; some follow "code, you're done," and get to their destination; some change toolbelts every six months and yet, two years later, have something that works.Dr. Grabriel, please don't tell me what sometimes works. Tell me what often helps in general; tell me what makes a difference for the better for various particular kinds of projects.
Couple of other complaints: He talks about Jini in the past tense as if it's been a wonderous success; I agree it's promising, but nothing more, yet. He also talks about the horror of modules and the wonder of (what everyone else calls) components; I wish he'd distinguished the two (and their respective weaknesses and strengths) better. (Okay, maybe that last is my weakness and not his.)
(I did not intend to use so many parentheses when writing about a Lisp uber-meister-hacker (but it's kind of appropriate (now that I think about it)).)
Stupid job ads, weird spam, occasional insight at
First of all, sure NASA had a number of rockets fail and crash. Think how much worse it would be if they opened up the space project to anyone and everyone who wanted to participate in it. Despite what the essay says, lunar missions needed to have structure and organization. There are always variables involved - but I don't think they ever believed otherwise. They're merely trying to apply the laws of physics and math to the best of their ability to reduce the risk, and build something that works as often as possible.
Likewise, programmers don't use tools like UML because they believe it reduces the number of bugs in their code. They do it to keep themselves organized and focused on a set of design goals.
This "mob programming" idea seems to me like just another thought in someone's head that generates a lot of hype for a little while, but has no real substance.
The larger a project gets, the more people get involved. This is just common sense. The best projects come from using the best educated/trained individuals for the projects. Open source works well because only people with a given level of interest + experience feel compelled to contribute to a given project. It's sort of an "automatic filter", because there aren't any financial rewards which might otherwise encourage lesser candidates to take on said projects.
Oh, please. Earthquakes in heavily populated first world communities such as Los Angeles and Tokyo kill dozens of people. Earthquakes in heavily populated third world communities such as Turkey and Iran kill tens of thousands of people.
I couldn't resist
I'll make him an OS he can't refuse
Truly sorry for that
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Hmmm, anything like Klingon software development?: The top 15 things likely to be overheard if you had Klingon programmers working for you: (extended from Tom Fevens' CISC 121 course web page) 15) "This code is a piece of crap! You have no honor!" 14) This machine is a piece of GAGH! I need dual Pentium processors if I am to do battle with this code. 13) You cannot really appreciate Dilbert unless you've read it in the original Klingon. 12) By filing this bug report you have challenged the honor of my family. Prepare to die! 11) I have challenged the entire Quality Assurance team to a Bat-Leh contest! They will not concern us again. 10) "Our competitors are without honor!" 9) You question the worthiness of my code? I should kill you where you stand! 8) Debugging? Klingons do not debug. Our software does not coddle the weak. 7) Klingon function calls do not have "parameters" - they have "arguments" - and they ALWAYS WIN THEM 6) Indentation?! I will show you how to indent when I indent your skull! 5) A TRUE Klingon warrior does not comment his code. 4) Specifications are for the weak and timid!! 3) "Perhaps it IS a good day to die! I say we ship it!" 2) Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! 1) What is this talk of 'release'? Klingons do not make software 'releases'. Our software escapes, leaving a bloody trail of designers and quality assurance people in its wake!
If you look at the sites which discuss Design Patterns from fundamentals (which is how we got Analysis Patterns, Design Patterns etc) then you see that those guys regard Patterns as a deep deep philosophical exercise. This is Meta Design. Alexanders works are like Euclids elements here ... they are the ultimate abstraction ... thats why they resemble poetry and thats why effective design patterns have little to do with code but about 'vague' descriptions of problems , costs, benefits and solutions. Which is why they work.
Bitter and proud of it.
I'd rather have concise articles on the front page than have Taco's opinion shoved down my throat. Yeah, I'll get modded down for this. Good thing I don't care about karma. Yeah, my concious decision to read /. does not constitute having an opinion "shoved down my throat". Get over it. Please don't patronize me with history lessons.
I've always found that when I build a website, or any project for that matter, it evolves slowly into what I want. It doesn't really seem to matter how ~many~ people are working on it. It just takes time to all come together.
-io
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
"Among the main volunteers to the OED project was Dr. William C. Minor, a brilliant etymological worker who, during his entire 30 or so year involvement with the OED, happened to be locked up in an asylum for the criminally insane, where he suffered hallucinations that kept him awake all night most nights and where he eventually mutilated himself in the most horrific manner. Once incarcerated, he was never entirely outside immediate and confining care. Yet he was acknowledged as one of the most important contributors to the project."
What does that tell you about this entire idea?
The idea also doesn't really seem revolutionary. All they really do in the article is complain about engineers being people that tinker too much and that big software projects should have lots of people that work on them.
Isn't there usually a large amount of programmers to a large project? I never really thought of this as an issue.
When all freedom is outlawed only the outlaws have freedom
Never Underestimate the Power of Stupid People in Large Groups.
A good quote I've seen somewhere to summarize my opinion on the matter. Well, the stupid part is arguable, but you get the picture.
So, you will be wanting our services huh?
Something about an infinite number of monkeys and typewriters.
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.