Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Mob Software 234

Posted by michael from the get-the-torches dept.
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.
This discussion has been archived. No new comments can be posted.

Mob Software More

Mob Software

Comments Filter:
  • 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?
  • "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.

  • Then I actually read the article (Score:5, Funny)

    by Aerog ( 324274 ) on Wednesday August 15, 2001 @04:51PM (#2112302) Homepage
    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. . .

  • Maybe the perception; not the reality (Score:5, Insightful)

    by WillSeattle ( 239206 ) on Wednesday August 15, 2001 @04:51PM (#2112304) Homepage
    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.

  • Am I the only one who thought it was odd that this was written by Ron Goldman. I thought OJ did him in!
  • 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.
  • The essay begins: "That way of hacking you like is going to come back in style"

    Here's a spoof story [bad-managers.com] on so-called hacking methodologies.

    Okay okay, I know it isn't totally on-topic but it's worth a read anyway...

  • 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.

  • Many Hands Make Shite Work (Score:4, Insightful)

    by Looge Over All! ( 454290 ) on Wednesday August 15, 2001 @04:48PM (#2120264)
    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.
    • 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...

    • Anyone who could even mention a deeply thought out essay by Richard Gabriel in the same paragraph with "Inexperienced developers," is himself, wet behind the ears.

      Do you even know who the author is, and how much software expertise and experience he has, both in academia and the business world?

      Read carefully and think before shooting off your mouth.

    • The other half (Score:3, Insightful)

      by Srin Tuar ( 147269 )

      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.

      • 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.

        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:

        A person can decide to leave the ecosystem without leaving behind a substantial "carcass" that can be reclaimed as nutrients for it.

        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:

        Okay, Mob Software Proposer guy, what's the next step?

        ;-)

        • 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.

          No one says that bazaar style programming will cure individual ignorance. Nor does anyone claim that some arbitrary problem will be solved in some arbitrary amount of time.

          Free programmers will create what they create when they create it, and alot of it will be good. The whole of it all taken together will be yet greater than the sum of the individual parts.

          Given time, this could become the dominant pool of software creation. Some might say it already is...

  • What does a Mob do? (Score:2, Insightful)

    by pkesel ( 246048 )
    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.

  • Mob software? (Score:2, Funny)

    by jpm242 ( 202316 )
    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
  • 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."

  • would you buy a used car from this model? (Score:3, Insightful)

    by tim_maroney ( 239442 ) on Wednesday August 15, 2001 @05:02PM (#2121705) Homepage
    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. That is how "Mob software" projects are run. It's a well-known recipe for bad software. Its results are unreliable, slow, and impossible to maintain. Command and control systems are required for synchronized execution of a coherent plan.

    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

    • 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.

      • 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)..

    • Re:would you buy a used car from this model? (Score:1, Insightful)

      by Anonymous Coward
      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.
      • 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.

        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

    • "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.

    • > I can't imagine anyone being willing to buy a house that had been built with no architect, no blueprint and no foreman...

      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.

  • Finally (Score:5, Funny)

    by MeowMeow Jones ( 233640 ) on Wednesday August 15, 2001 @05:01PM (#2123026)
    A software methodology that has a stupider name than "X-Treme Programming"

  • poets (Score:2, Funny)

    by jxqvg ( 472961 )
    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 [britneyspears.com], members of the band Metallica [metallica.com], and popular rap artist Eminem [eminem.com] point out to us.
  • If software made by mob, then slashdot would be populated by mobsters. What would that look like?

    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

  • 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...
  • Well, as long as everyone else thinks we should be "mob programming", I guess I should too... :)

  • 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.

  • My problems with this essay (Score:5, Insightful)

    by iabervon ( 1971 ) on Wednesday August 15, 2001 @05:14PM (#2128902) Homepage Journal
    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?
  • Mr. Gates never asks a second favor once he's refused the first, understood?

  • Gather up some angry villagers... (Score:5, Funny)

    by JesseL ( 107722 ) on Wednesday August 15, 2001 @05:58PM (#2131391) Homepage Journal
    You bring the pitchforks and I'll get some torches. We'll have Mozilla 1.0 out in no time!
  • My brother once had an idea for a short science fiction story. Imagine aliens are parked out on the edge of the solar system monitoring us? When they notice our reverence for gold they attempt to get on our good side by mining a huge chunk of it from, say, Charon. Then they come prancing towards Earth saying, "We come in peace. We bring you gold." Well, what do you think the Earth governments would do? They'd point every nuke on the planet at the BEMs and reduce them (and the gold) to their constituent components -- can't have him fscking up the whole world economy, now can we?

    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.

    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 .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.

    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.
    • 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!
    • This writer is wondering what software will be like when all code can evolve, and interact, and what that emergent behavior might be like.

      I think someone aleady thought of that...

      "The SkyNet funding bill is passed. The system goes online on August 4, 1997. Human decisions are removed from strategic defense. SkyNet begins to learn at a geometric rate. It becomes self-aware at 2:14am Eastern time, August 29. In a panic, they try to pull the plug."
      "And, SkyNet fights back."
      --
      Terminator 2: Judgement Day

      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.

  • I was surprised and pleased to see references to Stuart Koffman in this essay.

    The research being done at the Sante Fe Institute [santafe.edu] 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...

    • "You are the product of a mutational union of ~640Mbytes of genetic information."

      Hey, didn't Bill Gates once claim that nobody would ever need more than 640MB of genetic information?

  • Maybe the next one will be funny.
  • 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?

    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 /. is read by vocal code poets and a horde of lurking team developers. I see the team developers speak up every now and then.

    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 :) j/k

    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.
  • When I saw the headline I thought this might actually be about what kind of software the mob uses when using computers in aid of their illegal activities. Which would actually be an interesting thing to learn about, but I was afraid it was motivated not so much by technical interest as "Soprano" bandwagon jumping. Criminals don't really need to be glamourized.

    But the really frightening part was the vision of Linus waking up to find that Bill left a penguin head in his bed.

  • Software should be written while you smoke a big fatty.

  • Mob Software??? (Score:3, Redundant)

    by JBowz15 ( 451573 ) on Wednesday August 15, 2001 @04:48PM (#2135695)
    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.
  • 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 :)

  • A bit dated... (Score:5, Informative)

    by Lizard_King ( 149713 ) on Wednesday August 15, 2001 @04:54PM (#2138736) Journal
    Richard Gabriel gave this speech at theOOPSLA 2000 Conference [acm.org] (Object Oriented Progamming, Systems, Languages & Applications). There are some other interesting keynote presentations there including a piece on Adaptive Software Engineering [acm.org] (PDF Alert!!).

    You can download a .pdf of the essay [laputan.org], or if you can't view pdf's, check out the cover [laputan.org].
  • Reference: The Cathedral and the Bazaar [tuxedo.org]



    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.

    • Re:How is it different from "The Bazaar?" (Score:5, Insightful)

      by denshi ( 173594 ) <toddg@math.utexas.edu> on Wednesday August 15, 2001 @07:10PM (#2124827) Homepage Journal
      Firstly, it's written by Richard Gabriel. You young 'uns might not know him, but us old school LISPers listen, and intently to what he has to say. Accomplishments? One of the original LISP hackers, professor at Stanford, master of all things OOP, founded and buried Lucid, written a huge pile of enriching documentation. ESR, whatever the merits of his fetchmail and Python work, doesn't have that cred level yet.

      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.

      • Your post is terribly underrated, and mine is terribly overrated.

        Thanks for pointing that out. I re-read the article, and you're right -- this is a truly enriching read. It's the sort of thing where even if you disagree with it, you're enriched just for thinking about what he addresses.
    • 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.
  • 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.

    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 ;) 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.

    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.

  • Too big for Slashdot. (Score:3, Insightful)

    by Perianwyr Stormcrow ( 157913 ) on Wednesday August 15, 2001 @06:31PM (#2140177) Homepage
    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.

  • so let me get this straight... (Score:5, Funny)

    by Telek ( 410366 ) on Wednesday August 15, 2001 @04:38PM (#2140322) Homepage
    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!
    • As long as you have some organization, it will work, though. Er, Linux?

      /Brian

    • Missing the Point (Score:2, Insightful)

      by Catskul ( 323619 )
      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).

  • Scene: A crowded room... (Score:5, Funny)

    by whatnotever ( 116284 ) on Wednesday August 15, 2001 @06:11PM (#2141038)
    ... 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!
    • 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...

  • I swear I've seen this before... (Score:4, Funny)

    by gnovos ( 447128 ) <gnovos.chipped@net> on Wednesday August 15, 2001 @06:48PM (#2141208) Homepage Journal
    ...something about an infinite number of monkeys on an infinite number of typewriters. It could work... :)

  • 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.

  • Invited talk at OOPSLA 2000 (Score:5, Insightful)

    by Stu Charlton ( 1311 ) on Wednesday August 15, 2001 @04:59PM (#2141904) Homepage
    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" [fatbrain.com].

    Cheers

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Wednesday August 15, 2001 @04:41PM (#2141955)
    Comment removed based on user account deletion

  • Well that's informative... :-/ (Score:4, Informative)

    by HongPong ( 226840 ) <hongpong@Nospam.hongpong.com> on Wednesday August 15, 2001 @04:41PM (#2141956) Homepage
    Logically, slashdot is supposed to summarize news, not say basically nothing. All right, software should be developed by a mob. How is that significantly different from how things are today with mid-sized OSS projects? Come on, Tim, give us more than a single thought. What are the merits of this essay? Some details? How does it contrast with other OSS development models?

    I get the news I pay for, I guess.

  • Some corporations get into this mode. There are companies that run on a bunch of Excel spreadsheets and Visual Basic programs. The usual result is an unmaintainable mess. But it sort of works, because they can't mess with the core engines, the OS, database, spreadsheet program, and language systems.

    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.

  • ...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.

  • Hard to swallow (Score:3, Funny)

    by Illserve ( 56215 ) on Wednesday August 15, 2001 @04:59PM (#2144061)
    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...

    • 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.

  • Coding with the fishes, see (Score:5, Funny)

    by Nastard ( 124180 ) on Wednesday August 15, 2001 @04:40PM (#2144161)
    I don't know what he's talking about. There's no mob mentality on the internet. The web is a place where individuals can share unique and sometimes conflicting ideas in a positive manner. To imply that there is any kind of groupthink...

    I just realized where I was. Tra la la.
  • I would dare to guess that the writer of this article is quite likely to be an INFP [personalitypage.com] personality according to the Myers-Briggs [humanmetrics.com] personality type classification system.

  • Mob developed software - hmmmm... (Score:5, Funny)

    by JanneM ( 7445 ) on Wednesday August 15, 2001 @04:38PM (#2154068) Homepage

    "I will give you a patch you cannot refuse"

    Well, it might work :-)

    /Janne

    • I was thinking more along the lines of:

      "Don Cox, Don Perens requires your presense at..."

    • 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

  • I've met Richard Gabriel. I've read Richard Gabriel. Friends, I'm no Dick Gabriel. I'm not worthy to close his open parentheses.

    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)).)
  • First, a general comment about the article. Maybe I need to re-read it again, but I got the impression that the authors were dancing from one topic to another without really tying them together. It may make for interesting prose, but it really detracts from their arguments.

    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.

  • Mob software is ill conceived (Score:2, Insightful)

    by Anonymous Coward
    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 [stileproject.com] 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.

Slashdot Top Deals

If entropy is increasing, where is it coming from?

Close