Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming Businesses IT

Disproving the Mythical Man-Month With DevOps 281

StewBeans writes: The Mythical Man-Month is a 40-year old theory on software development that many believe still holds true today. It states: "A project that requires five team members to work for five months cannot be completed by a twenty-five person team in one month." Basically, adding manpower to a development project counterintuitively lowers productivity because it increases complexity. Citing the 2015 State of DevOps Report, Anders Wallgren from Electric Cloud says that microservices architecture is proving this decades-old theory wrong, but that there is still some hesitation among IT decision makers. He points out three rookie mistakes to avoid for IT organizations just starting to dip their toes into agile methodologies.
This discussion has been archived. No new comments can be posted.

Disproving the Mythical Man-Month With DevOps

Comments Filter:
  • by ruir ( 2709173 ) on Tuesday October 06, 2015 @05:46AM (#50668645)
    Love the smell of coffee plus bullshit in the morning.
  • by Anonymous Coward on Tuesday October 06, 2015 @05:49AM (#50668651)

    ... it was a rule of thumb and a good one, because it was talking about how not all projects are scalable and the observation is bound to the historical time period in which it was coined. If some new unknown advance or theory came along, it doesn't disprove the ideas of the mythical man month. Because that observation is bound to certain contexts and certain projects.

    This is what happens when you take an observation out of its context both historical and otherwise.

    • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday October 06, 2015 @06:30AM (#50668783) Journal
      I don't know how broadly it can be applied(if it in fact works as well as they claim at all); but it would appear that the whole point of these 'microservices' is to produce smaller 'projects' so that you have more room to scale before complexity eats you alive. It's not so much a disproof of the 'mythical man-month'; but an adaptation to cope with it.

      Getting purely linear scaling without some sort of zero-latency hive mind is unlikely to be possible; but it seems fairly obvious that the amount of overhead you incur by adding 20 extra people to a five man project is going to be rather higher than adding a second person to a one man project(though the jump between 1 person and 2 people might actually be pretty big, if helpful in terms of producing documentation that somebody other than the 1 person understands). If you can break your projects down into smaller pieces, with complexity better contained, and well defined interaction between the pieces, you have teams small enough that you might actually be able to make them faster by making them somewhat larger.

      If your project is already a screaming heap of interlocking complexity, there simply isn't as much work that can be done in parallel. Aside from people stepping on each other's toes, there will just be a lot of "Part X can't be done until the guy doing Part Y finishes".

      Not so terribly different(if likely to be even less predictable because humans are involved) than deciding how a problem will scale if you throw more computers at it. If your problem is actually a large number of mostly unrelated problems, it'll scale nearly perfectly. If your problem consists of lots of somewhat interconnected problems it will scale; but demands on interconnect will become increasingly expensive. If it's a purely serial problem, and each step depends on the prior step, it may not scale at all.
      • by gmack ( 197796 )

        It Is an adaptation to cope with it but you still lose time building APIs and tracking API's of the "micro services" that you are using. The tradeoff is still there.

      • Great point, were it not for the fact that Agile produces garbage. Always has, and always will.
        • by dave420 ( 699308 )
          Except where it does not, of course. Or are you saying all the successful projects which used Agile methodologies to be created don't exist?
          • Except where it does not, of course. Or are you saying all the successful projects which used Agile methodologies to be created don't exist?

            Not really - even a stopped clock is right twice a day. As far as TFA is concerned, though, I find it absolutely hilarious that the agile fanclub has now gone so far as to "prove" MMM wrong on a very foundational level. Let me be clear: there are a class of problems that cannot be solved just by working more energetically.

            If you think you've solved the halting problem, you're naive.

            If you think you've produced sentient AI, you're naive.

            If you think you've disproved "throwing more programmers at a late proj

            • Not really - even a stopped clock is right twice a day. As far as TFA is concerned, though, I find it absolutely hilarious that the agile fanclub has now gone so far as to "prove" MMM wrong on a very foundational level. Let me be clear: there are a class of problems that cannot be solved just by working more energetically.

              I'm part of the "agile fanclub" and I actually am constantly telling people that the whole reason for Agile is because of the truth of the Mythical Man-Month. Agile is not a silver bullet and if someone told you it is, then they didn't understand Agile. Agile values, principles and tools (such as Scrum or XP), give us an environment where we recognize the limits of complexity and communication and help us maximize goodness (productivity and happiness) given those complexity and communication limits.

              Extraordinary claims requires extraordinary evidence, and the claim made in the summary is in the same class of all other extraordinary claims, hence we require more than a simple "here's why our claim might be true".

              Strong

            • Let me be clear: there are a class of problems that cannot be solved just by working more energetically.

              Actually, TFA specifically says you'll most likely have to re-architect the product/application/problem *first*, before you just throw energy at it. TFA also goes on to say that you have to fundamentally change the structure of your organization if it isn't suited to the task (e.g. siloed orgs, etc).

              No where in TFA does it say you have to simply throw more resources at the problem.

              In fact, it even goes so far as to say that not all problems/projects are adaptable to this:

              One thing CIOs need to understand is

          • No, I'm saying if they were successful it was in spite of Agile, not because of it.
      • by Bengie ( 1121981 )
        Adding one extra person to a one person team could have super linear speed improvements. Many times, very small groups can gain more efficiency than overhead in addition to increased throughput. I've seen similar things with some multi-threaded programs that I've written, where I saw an overall increase of cache hits when running two threads because the datasets were small.

        In my personal case at work, I do a lot of creative work when designing systems, and that requires a decent amount of mental down time
      • I don't know how broadly it can be applied(if it in fact works as well as they claim at all); but it would appear that the whole point of these 'microservices' is to produce smaller 'projects' so that you have more room to scale before complexity eats you alive. It's not so much a disproof of the 'mythical man-month'; but an adaptation to cope with it.

        In other words, divide-and-conquer meets software project management. That is how it has been done to deal with these issues, for a long time before micro-services. And microservices would not help if the project, the totality of the project is late. The issues related to MMM's postulates are, for the most part, technology agnostic.

        And in fact, the fundamental problems are not technology-based, but organizational/political ones. I love microservices, but they are, in the great scheme of things, a technic

    • by angel'o'sphere ( 80593 ) on Tuesday October 06, 2015 @07:27AM (#50669069) Journal

      Considering that to start a project a developer needs two or three or more weeks to even really start working, I doubt hat the imagined 25 developers can finish in the remaining one or two weeks anything.

      Combining DevOps, Micro Services and Mythical Man Month into one headline makes no sense anyway.

      Since when does a DevOp develop a micro service?

    • I would go a step further and say that any company or research making such an out of context claim should be avoided at all costs. If they can't understand the context of such a basic statement then I seriously don't want to rely on them for anything else.
    • It is much the same concept of parallelizing algorithms. Some algorithms are easily parallelized where each unit isn't dependant on the other. Then you have others which cannot be parallelized, Things need to happen in that order and the start of the next step is dependant of the part of the first. The same with development projects. In order for someone to complete a particular section they need the results from an other. Then you have the difference between academic vision of software engineering, an

    • And one needs to read the essay, to realize WHY Brooks said what he said.

      His problem was not with technology or architecture, but with project management. The bigger the team, the more potential paths of communication between individual members, the better the project management needs to be to minimize communication down to the necessary minimum.

      If there is one BS that needs to be called, it is the one on the "collaborative open plan office". Which would be slightly off-topic, and all but beaten to death.

      • If there is one BS that needs to be called, it is the one on the "collaborative open plan office". Which would be slightly off-topic, and all but beaten to death.

        You can never beat that ill-begotten bullshit idea to death. In fact, it needs to not only die, but have its corpse beaten until each subatomic particle is separated from the other, then have the whole mess carefully scattered to the four winds.

    • The first book on the subject was titled "The mythical man-month"!!!

      The same way the waterfall model had always been a counter- example.

      "discovering" that those models are worse than your current faddish methodology is like finding that your new "locomotion revolution" beats square wheels.

      Get off my lawn.

  • Rule #1 (Score:5, Insightful)

    by Anonymous Coward on Tuesday October 06, 2015 @05:49AM (#50668653)

    Don't spend all of your on Atlassian products. The last three startups I worked for bankrupted themselves with products and process and project managers and certified scrum managers. I spent more time moving little fake post-it notes around or searching for "issues" on JIRA than I did actual programming.

    • Re: Rule #1 (Score:3, Insightful)

      by Anonymous Coward

      Our certified scrotum master made more than any of our developers and added no value. He actually cost us since he wasted about an hour a day of every developer's time.

      • Re: Rule #1 (Score:3, Interesting)

        by Anonymous Coward

        After finishing our six hour sprint planning meeting today, we waste more than an hour a day because of Agile. We do sprint planning every seven business days. About two hours of the meetings are wasted fighting JIRA bugs.

        • Re: Rule #1 (Score:2, Insightful)

          by Anonymous Coward

          Those long meetings are brutal. According to Agile, you must score enough stories to keep everyone busy the entire sprint. If you want to beat the mythical man month, getting rid of Sprint planning would go a long way towards that.

        • by Zalbik ( 308903 )

          Then you aren't using agile. Or not correctly at least.

          One of the most important concepts of agile is to identify problems in the process and eliminate them.

          If JIRA is slowing the dev team down, that should be identified in a retrospective & addressed.

          Also, a 6 hour sprint planning for 1 week sprints is excessive. The "out of the box" number is 2 hours/week.

          Finally, 1 week sprints are quite fast. Typically they should be used for prototyping or by a startup. In either of these cases, the planning "

    • AAAARG!!! I can't believe that Atlassian is making so much on this crap. JIRA is the WORST POSSIBLE CHOICE for an Agile environment. The very first value of the Agile Manifesto is "Individuals and interactions over processes and tools". (Agile Manifesto [agilemanifesto.org])

    • by MobyDisk ( 75490 )

      Experience shows me that this problem is not limited to companies using JIRA. And some of the competing products aren't that great either. In my personal survey of local developers, the companies that love Agile the most aren't actually following the process: but they don't know or care. The ones that drank the kool-aid and try to stick to it function they way you described. The first group says things like "We do resources planning in Microsoft Project or on a big sheet of paper" and "We don't bother w

  • Thinking that microservices is a silver bullet.

    This idea surfaces every now and then. It certainly has its uses and no doubt there are scenarios where you can beat the mythical man month.

    • Microservices have some legitimate criticisms [wikipedia.org]; it seems like you should only embark on that quest if you really know what you're doing and it's the best solution to your specific problem. It might be useful for expanding a monolith which is out of control, or for performance/language reasons in some cases, but building a whole system from microservices looks like it would be needlessly complicated once you delved in.

    • by mwvdlee ( 775178 )

      The mistake is thinking ANYTHING is a silver bullet.
      If you think you know a solution that will fix all problems, you haven't seen enough problems yet.

  • wrong premise? (Score:5, Informative)

    by cassidyc ( 167044 ) on Tuesday October 06, 2015 @05:57AM (#50668685)

    I was under the impression (having actually read The Mythical Man Month) that the premise actually was "adding manpower to a late software project makes it later" which is not the premise being discussed here.

    • Re:wrong premise? (Score:4, Insightful)

      by luis_a_espinal ( 1810296 ) on Tuesday October 06, 2015 @06:13AM (#50668735) Homepage

      I was under the impression (having actually read The Mythical Man Month) that the premise actually was "adding manpower to a late software project makes it later" which is not the premise being discussed here.

      Exactly. I call bullshit on whoever made the wrong claim that DevOps proved TMMM wrong. This is a case of software professionals not knowing what the hell they are talking about.

      • This is a case of software professionals not knowing what the hell they are talking about.

        That would be true all of the time.

    • Plus the bloody "state-of-the-art" report is nothing more that a few bullet points with a form for collecting personal information. Lamest click-bait ever.
    • by jrumney ( 197329 )
      In any case, finding that a good architecture to start with helps make scaling from a 5 person team to a 25 person team reasonably free of overhead, does not mean that scaling will continue to teams of 100 or 1000 as are typical in enterprise scale failed projects.
    • by pdunkin ( 731187 )
      Yes! Mod parent up!
    • by havana9 ( 101033 )
      Actually the example in luxury cars is plain wrong. Maserati cars are built on an assembly line. And an assembly line literally full of robots [wired.it].
    • I think it's the same premise, but inverted. Management thinks the project will be finished faster if adding more man-power, but actually the inverse happens, it will be finished even later.
      A logical fallacy is not taking into account the complexity of a task. If one woman makes a baby in 9 months, 9 women should be able to make a baby in 1 month.
      • Management must be pretty stupid then. I read the book after a year or so of being out of university and working in the industry, and just about everything in the book seemed pretty obvious. I guess if you come from a manufacturing or construction background, there might be some ability to add people later in the game to bring a late project back on time, but I imagine there's limits even in those fields. Anybody who thinks you can just throw more people at a problem in a field like software development d

        • I've read the book a couple of years ago, and in my Software Engineering courses in college in the 90s, the same thing was said. Also 15 years in the industry and I've heard the line "If you can't make it on time, we'll add more people to the project" over and over again. Mostly by clueless Project Managers without a CS/SE background.
    • I was under the impression (having actually read The Mythical Man Month) that the premise actually was "adding manpower to a late software project makes it later" which is not the premise being discussed here.

      That is correct, along with my favorite paraphrase, "Programming time is not fungible". Regarding the summary, perhaps the author should seek the advice of The Doctor: "Answers are easy. It's asking the right questions which is hard."

    • I don't think it's quite that. It's more like, "adding manpower to a project will not necessarily speed it up." The famous example is "9 women can't make a baby in 1 month."

      Adding manpower may help a project get done faster. It may make it take longer. It may make no real difference. It depends. It seems like what's being discussed here is that someone thinks they have disproved the concept, when really they just found one specialized situation where "it depends".

  • Microservices may help parallelisation in one are, where the services are implemented. Designing and specifying the services and interfaces, then integrating and testing will have a complexity overhead. Also coordinating fixes and releases over a large number of developers will take longer. In most projects the advantage will be limited.

    Remember when the mythical man month was written a microservice-like architecture of text based systems using lots of discreet Linux programs and pipes was quite common and

    • by dwywit ( 1109409 )

      No, I don't remember that, seeing as how TMMM was published in the 70s, and Linux was released in the 90s.

      If you meant Unix, then you're getting closer temporally, but you've still missed the target.

      I'll assume your auto-correct substituted "Linux" when you really meant "OS360", but I'd like to see some examples of "discreet OS360 programs and pipes" to support your statement.

      • by Chrisq ( 894406 )

        No, I don't remember that, seeing as how TMMM was published in the 70s, and Linux was released in the 90s.

        If you meant Unix, then you're getting closer temporally, but you've still missed the target.

        I'll assume your auto-correct substituted "Linux" when you really meant "OS360", but I'd like to see some examples of "discreet OS360 programs and pipes" to support your statement.

        No I meant Unix

        • by mwvdlee ( 775178 )

          Too bad, because the book constantly references OS360, whose development was the inspiration for the book.
          It's been a while since I've read it, but I don't remember it mentioning Unix, atleast not in any significant way.

          Back in those days you typically has many small, single-purpose programs "piped" using files, regardless of the specific OS.
          Given the small memory sizes available, this was pretty much the only way to handle large jobs.

          • by Chrisq ( 894406 )

            Too bad, because the book constantly references OS360, whose development was the inspiration for the book. It's been a while since I've read it, but I don't remember it mentioning Unix, atleast not in any significant way.

            Back in those days you typically has many small, single-purpose programs "piped" using files, regardless of the specific OS. Given the small memory sizes available, this was pretty much the only way to handle large jobs.

            It's been a long time since I read it, I'm sure your right,

        • by dave420 ( 699308 )
          Then you were still wrong. OS360 is not Unix. You xenophobes are not usually known for your factual awareness, but well done for admitting you were wrong.
    • Multics, on which Unix was based, was in the mid 1960s. OS370 had interprocess communication and multiprocess file access. Believe it or not, there WERE real computer systems before Unix and Linux, and don't let the garbage of DOS and Windows block your awareness of the tremendous amount of research and intelligent thought that had gone into systems before them.
  • by eulernet ( 1132389 ) on Tuesday October 06, 2015 @06:14AM (#50668741)

    Dear Anders,

    I know you are trying to defend your point of view, that DevOps is THE solution to everybody's problems.

    I agree that divide-and-conquer is an approach useful in algorithms (especially if you pass Google's recruitment tests), but it's much more difficult in real life.

    Social loafing exists in groups, and has been known since a long time.
    Ringelmann measured the productivity at the beginning of the twentieth century, and discovered what is now named Ringelmann effect:
    https://en.wikipedia.org/wiki/... [wikipedia.org]
    Ringelmann's original article explains that a team of 8 persons produces the work of 4.
    You may argue that you can optimize that by splitting in several groups, but the effect exists starting at 2 persons (85% of effort is produced).

    To a certain degree, you can optimize a process by splitting tasks in independent subtasks, preferably assigned to one person each.
    However, there are several major problems:
    1) some tasks are not as independent as you may imagine
    2) some tasks require that people with multiple domains work on them
    3) some tasks are so long that it slows down the entire process. It is well known in Supply Chain that a single bottlenecks reduce your output.
    4) splitted tasks become boring as hell
    5) working alone doesn't improve your knowledge

    So no, you didn't show that the Mythical Man-Month has been disproved.
    You just showed that dividing tasks to a certain level may improve productivity, which is nothing new.

    Also, applying efficiently DevOpt requires experienced managers.
    Experience comes from mistakes and mixing various techniques, like ITIL, Scrum, DevOps, etc.
    If you only use DevOps, I can assure you that you are bound to fail !

    • by tomhath ( 637240 ) on Tuesday October 06, 2015 @08:22AM (#50669317)

      To a certain degree, you can optimize a process by splitting tasks in independent subtasks, preferably assigned to one person each.
      However, there are several major problems:
      1) some tasks are not as independent as you may imagine
      2) some tasks require that people with multiple domains work on them
      3) some tasks are so long that it slows down the entire process. It is well known in Supply Chain that a single bottlenecks reduce your output.
      4) splitted tasks become boring as hell
      5) working alone doesn't improve your knowledge

      In my experience, your first point is where most attempts at microservices fail. Someone designs a monolithic application - then management chops it up into little pieces and thinks they have microservices. But they don't have microservices because all the same interdependencies are still there. All they have are chunks of a bigger program.

      • Mod parent up, if I had any points. I worked on a project where the designer kept insisting that his design was decomposed and structured . . . yes, the little pieces all fit together - like a jigsaw puzzle, only one very specific way. "Structured" implies some kind of consistent interface, like Lego blocks that can be interchanged or moved or reused, not like a jigsaw puzzle.
  • The latest report from my organization (please click on all the links and give me loads of personal information to sell) has disproved mythical woman month. The original myth holds that you can not get nine women pregnant and get a baby in one month. The absolutely latest and greatest agile methodology with Kanban technology and our copyrighted and patented bullshittology technique has totally disproved that theory. Come one, click, gimme my money. What are you waiting for?
  • by Anonymous Coward on Tuesday October 06, 2015 @06:59AM (#50668923)

    It's just a management term for making developers do support, and support staff try and develop. It's a fancy name for being "promoted' into doing 2 jobs.

  • by taikedz ( 2782065 ) on Tuesday October 06, 2015 @06:59AM (#50668925) Homepage Journal

    1/ The Mythical Man Month was "referenced" (and mangled) about in an unrelated article by Eddy Baldry. It is he who mis-states the premise of the MMM

    2/ Mythical Man Month's statement is "Adding more manpower to an already late project delays it further." This is different from the premise stated by Baldry.

    3/ Anders Wallgren mentions nothing of the Mythical Man Month

    4/ Wallgren actually does say that microservices, underpinning some of the arguments for DevOps, is not suitaed for all projects.

    5/ The summary is a lie.

    • by Zalbik ( 308903 )

      3/ Anders Wallgren mentions nothing of the Mythical Man Month

      Incorrect. From the actual article [enterprisersproject.com]:

      Wallgren: The major benefit of a microservices architecture is that you can actually start to beat the Mythical Man-Month (i.e. the long-standing theory that adding people to a project lowers, rather than increases, velocity).

      This indicates that Wallgren exactly said that microservices help you beat the MMM.

  • by Hognoxious ( 631665 ) on Tuesday October 06, 2015 @07:01AM (#50668937) Homepage Journal

    Submitted by StewBeans and posted by samzenpus. A link to enterprisersproject.com.

    The only logical conclusion is that some fucker is selling something.

  • by Anonymous Coward

    Partitionability is discussed in the book. Yes, if you can break a project down into small parts and work on those separately, then you can save time. The premise the OP incorrectly addresses is that some tasks cannot be broken down any smaller and therefore do not benefit from more people, and often are hurt because of the overhead of working together.

    There are many other suggestions in the book. Another popular one is don't add more people to a late project. Another is about having one chief and many

    • Yes, if you can break a project down into small parts and work on those separately, then you can save time.

      And if you could, you'd probably already be doing it.

  • You can't just speed up development teams by adding more team members.

    But the devops / microservices do help you to create an culture / architecture where you get more but smaller parts each with their own team.

    Thus you'd have more teams.

    So the project as a whole can might go faster if you can chop your software up in different pieces without any interdependence (which obviously doesn't always apply to all problems).

  • by Anonymous Coward on Tuesday October 06, 2015 @08:37AM (#50669395)

    I've managed software development teams for 10+ years.
    It's really fucking simple: as a manager, if you wanna do a good job, you have to 1) serve as the shield that protects your devs from the shitstorm of politics and stupidity that goes on at the highest level, so that it doesn't distract them and they can, you know, build shit, and 2) choose the right devs in the first place (the difference in productivity between a good dev and a mediocre dev can be fucking scary, let me tell you, we're talking 20x sometimes)

    That's it. Choose the right devs, let them do their work, make sure you make their obstacles vanish in advance. All this agile and scrum and shit, I've tried it, it's crap; if you need it, you don't have the right team. The only management tool I need is a Trello board and github and meeting one-on-one with the devs every now and then because they'll never come up to you and tell you when they have a personal issue.

    • Sounds like you have it basically figured out. You keep the corporate politics BS from interfering, and I'll deliver an effective, reliable solution quickly.

      > choose the right devs in the first place (the difference in productivity between a good dev and a mediocre dev can be fucking scary, let me tell you, we're talking 20x sometimes)

      I don't know, an average developer can produce quite a bit of technical debt very quickly. That's productivity, right? :)

      Message me when you're hiring.

  • by Shados ( 741919 ) on Tuesday October 06, 2015 @09:01AM (#50669561)

    That stupid fad is created by small tech startups looking at how unicorn companies run, then bringing that in the big boy world and eventually going "What the fuck have we done?!"

    Yeah, if you microservice everything, you can ship those services faster. Much much faster. You redefined what it means to "ship". Instead of shipping a full feature, you shipped a tiny piece of one. But now that thing has to interact and be compatible with everything else that talks to it.

    At first, it just makes things easier. Until all the stuff you extracted into microservices become tech debt (well, they were tech debt to begin with: that's why extracting them out increased your velocity, and ignoring them is making you so much faster). You can't forget they existed forever...and it comes back. "Who knows what service XYZ does again?" "Look at that fucking outdated doc on the wiki! Good luck! Its in Perl 3!"

    And then you just massively increased complexity and trashed your velocity. It just happens later. Congratz, you can scale devops sky high...for a short of time...maybe a few years if you're good. Then it comes crashing down. But you can tell yourself its because you're not a "big company" and the "nimble startups" are catching up...until they make the same mistake.

  • by Theovon ( 109752 ) on Tuesday October 06, 2015 @09:35AM (#50669825)

    I'm sure you can find plenty of teams of rockstar coders who can scale in amazing ways. Unfortunately, this does not apply to teams of average programmers. An average programmer knows how to code but is typically much less intuitive about how their components impact other developers. To deal with this, you need to do all this up-front design work that it entirely serial (not scalable) and takes a substantial portion of the total development time.

  • Nothing scales linearly, but some things scale more linearly than others.
  • The lesson here isn't that you throw five times as many people at a project. The whole idea of microservices is they are small, interchangeable projects. If you split one big project into five smaller projects, you can have a small team do each project.

    This doesn't disprove anything about the Mythical Man-Month. It reinforces it. If you have multiple small, well-defined projects rather than one big, all-encompassing centralized project you can get the work done faster. If you want it all tightly integrated into a project the size of the 360, you need to wait.

  • Having managed projects ranging from R&D, defense systems, construction, and software development.. the MMM is all about work teams. Most successful project managers learn this sort of thing from experience (read pain and failure). Everybody thinks they have some sort of 'new concept' that is the magic bullet to 'solve software development problems'.

    Forgetting that the one common element is... people. No matter WHAT methodology you claim to follow, I guarantee at least half of your team will think it's

  • by jblues ( 1703158 ) on Tuesday October 06, 2015 @09:48AM (#50669935)

    Once again, this can be distilled down to an application of Amdahl's law, which states:

    If we have a process where 50% must occur in sequence, because of dependencies and prerequisites, while the remaining 50% can be farmed out across an infinite number of workers, then the speed-up given an infinite pool of workers is the reciprocal of 50% or two times. Not very impressive.

    Therefore to scaling up a team depends on management structures, lines of reporting and other I/O bottlenecks, and at any point we'll be either IO bound (communication is the limiting factor) or CPU bound (resourcing is the limiting factor.

    I didn't realize that Gene Amdahl is in fact alive and well [wikipedia.org], and also coined the term FUD (fear, uncertainty, doubt), which is popular, and well understood on Slashdot

  • Amdahl's Law (Score:4, Insightful)

    by rockmuelle ( 575982 ) on Tuesday October 06, 2015 @09:53AM (#50669973)

    The basic idea behind the Mythical Man Month is essentially Amdahl's Law for human (instead of compute) resources. At some point, there's just no getting around it.

    But, just like with parallel and distributed computing, there are always people who don't understand the basic tenets of it and think they've found a way to transcend it (I'm looking at you Hadoop users).

    Learn it and never forget it:
    https://en.m.wikipedia.org/wik... [wikipedia.org]

    -Chris

    • Gene Amdahl and Fred Brooks were both important players at IBM, each making essential contributions to the System 360. That's an interesting connection between MMM and Amdahl's law, undoubtedly they talked.

      As for TFA, misquoting Al Swearengen, "someone open a window, it smell like cat piss in here."

  • Or as my company likes to do. Lay off 4 people and tell the 1 remaining he still needs to do the 5 month project in 1 month.

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?

Working...