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.
I love it (Score:5, Funny)
Re: (Score:2)
Are you trying to tell me that there are no silver bullets?
Re: (Score:2)
Re: (Score:2)
Yeah, when did Slashdot become a craven press agent?
Re:I love it (Score:4, Insightful)
When Dice bought it.
Next!
Re: (Score:2, Insightful)
Re:I love it (Score:5, Informative)
Although your version has a certain roguish charm, I prefer the elegance of the original: "The bearing of a child takes nine months no matter how many women are assigned."
Re: (Score:2, Interesting)
Re: (Score:2)
Re: I love it (Score:5, Funny)
"The idea behind microservices is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together."
Wow. No ever thought of that before.
Re: (Score:3)
You know, we could apply this to older programs. We could take the routines and refactor them into smaller pieces... we could call them "sub" routines. What's cool is that you could iterate it and further refactor those into even lower level subroutines.
Wow... this could change programming!
Re: (Score:3, Insightful)
we should build an OS above this concept
Then we can ruin it with systemd!
Re: (Score:3)
Not a hard and fast rule... (Score:5, Insightful)
... 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.
Re:Not a hard and fast rule... (Score:4, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:3)
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:
Re: (Score:2)
Re: (Score:2)
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
MMM is not about technology (Score:2)
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
Re:Not a hard and fast rule... (Score:5, Informative)
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?
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:3)
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.
STOP! It has ALWAYS been mythical! (Score:2)
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.
Re: (Score:2)
It's like Moore's Law. It was never a law, merely an observation. It held true at the time, and for a surprisingly long time afterwards.
It still holds, generally speaking. The author of this article is mistaking his simplistic wishful thinking for insight.
As others have pointed out, it is not as if no-one thought of divide-and-conquer before, and there's nothing new in devops that would justify an expectation of different results.
Sooner or later, the author is going to rediscover the law of diminishing returns, and be saying "of course, you must have exceptionally competent people to make it work", as have all prior silver-bullet finders.
Rule #1 (Score:5, Insightful)
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)
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)
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)
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.
Re: (Score:3)
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 "
Re: (Score:2)
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])
Re: (Score:2)
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
Re: (Score:2, Informative)
after forcing Stash(Atlassian's attempt at a Git) server.
I guess you'll be glad to hear that Atlassian gave-up on Stash. I called the end of last week to upgrade our license, and our new salesdrone confirmed that it was being killed. He said he could no longer sell licenses to Stash. We're in a bit of a hard place right not, but this is great long term for us.
Re: (Score:2, Informative)
$350 per hour consultants to try to get a reasonable work flow
That is not uncommon. It took us over three years of work to get our workflow reasonable. In JIRA, we have issue types of bug, epic, user story, task, improvement, and new feature. Each issue type has its own workflow with between seven to twelve steps. The flowchart of how all of the types and steps work has over eighty boxes on it with over 200 lines(decisions). Needless to say many of our devs often spend more time mucking with JIRA than they do coding. The sad thing is that things are much bette
Re: (Score:3)
Re: (Score:3)
Getting equity in a project that doesn't get off the ground will sill end up with you working for nothing. It's not really "working my ass off for others' benefit", but "working my ass off for no one's benefit". I'm not sure that's much better.
It's a gamble either way, but sometimes I'd rather get a salary than equity.
Re: (Score:3)
Re: (Score:2)
I've never actually seen a Sharepoint implementation that worked out. Either nobody uses it, or management forces everyone to use it, and it turns into a big mess, and everyone hates it. I genuinely don't know of an appropriate use case for Sharepoint.
Rookie mistake number one (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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)
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)
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.
Re: (Score:2)
This is a case of software professionals not knowing what the hell they are talking about.
That would be true all of the time.
Re: (Score:2)
If you're doing projects where you don't have to do anything you haven't already done before, you should automate it.
Rigelmann Effect (Score:4, Informative)
MMM is largely used by software professionals as a bullshit soundbyte.
Yes, in the 1% chance you have a sufficiently advanced project requiring intimate knowledge of very funky code, MMM holds true.
Meanwhile, every other jackass is spouting, "Hurr, MMM!" for things like freaking CMS sites, where domain knowledge is widespread, easily attained, and frankly, not at all difficult to comprehend with a quick couple hours of looking at the code if you have any talent whatsoever.
And yet we still have people fucking it up and delivering late and/or the wrong CMS site functionality. And we still get managers throwing bodies at the problem that is already late/wrong (despite being conceptually simple.) It happens all the time regardless of system complexity.
MMM has nothing to do with projects requiring funky code. It is simple a software management rule: throwing more bodies to a late project won't make it go faster (in fact, it will make it default deadlines even more.) Whether is is a 1-man shop cobbling together a website or a 100-team developing a OS, if you are late, you are late, and no amount of additional manpower will change that.
That is what MMM is about. You complaining about it (or claiming it is a bs sound byte) shows you don't understand the meaning of it.
This is not even a software specific problem. Any type of complex project - from medical trials to inventory reconciliation, they all will suffer a bottleneck due to communication complexity.
Shit, even tomato picking gets affected. You have 100 laborers picking tomatoes, and you are late. Great, now you throw 100 more. But then, you do not have the logistics in place to handle the throughput within the given deadline. Depending of the severity of lateness, MMM (can't get shit late not being late with more bodies) will also hold.
It is simple and fundamentally a logistics problem, unless you actually think this is also a bs soundbyte. Google "Ringelmann Effect".
Indeed wrong premise + click-bait (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
9 women can't make baby in 1 month (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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."
Re: (Score:2)
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".
I'm not convinced (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:2)
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,
Re: (Score:2)
Re: (Score:2)
Divide-and-conquer is an art (Score:5, Insightful)
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 !
Re:Divide-and-conquer is an art (Score:4, Insightful)
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.
Re: (Score:2)
Next disproving Mythcal Woman Month. (Score:2)
DevOps isn't a thing (Score:4, Insightful)
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.
Who cooked up such a misleading summary?? (Score:5, Informative)
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.
Re: (Score:3)
Incorrect. From the actual article [enterprisersproject.com]:
This indicates that Wallgren exactly said that microservices help you beat the MMM.
A moment, Watson. Consider the following: (Score:5, Insightful)
Submitted by StewBeans and posted by samzenpus. A link to enterprisersproject.com.
The only logical conclusion is that some fucker is selling something.
has the OP ever read the book?!?! (Score:2, Informative)
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
Re: (Score:2)
And if you could, you'd probably already be doing it.
Misleading, but sort of true (Score:2)
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).
What good management is about (Score:4, Informative)
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.
yep. We should talk (Score:2)
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.
Freagin microservices (Score:5, Insightful)
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.
A few counter examples don't disprove the general (Score:5, Insightful)
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 (Score:2)
When you do microservices, it isn't one project. (Score:3)
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.
And the MMM is not just about software projects (Score:2)
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
Amdahl's Law (Score:4)
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)
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
Re: (Score:2)
As for TFA, misquoting Al Swearengen, "someone open a window, it smell like cat piss in here."
Or as my company likes to do.... (Score:2)
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.
Re: (Score:2)
The sticking point is whether or not snake oil can dissolve seemingly insoluble problems into lots of little, neatly contained, problems.
Re: (Score:2)
Problems, I think, in general come about because some issue to be solved is complex with interlocking parts. It all the parts were more or less disassociated from each other, they'd already have small solutions, and gluing them together might give a sort of federated solution to something that probably isn't such a big issue to begin with, mainly because the pieces are already doing the job and the interactions are minimal.
The problem with adding people is lines of communication forced by interacting proble
Re: (Score:2)
Re: (Score:2)
But it's a mashup! It's Dev from Development and Ops from Operations, mashed up together.
You've got to like mashups!
Re: (Score:2)
But there's no apps, which means it's for Luddites, right?
Re: (Score:3, Insightful)
Are you gonna be happier when they come with the same shit but just not call it "Agile"? Managers just want to manage, feel important, collect their bonuses. They are also afraid that if they are not noticeable enough they're gonna be fired for being unnecessary, which is true for most shit companies. Just like with sysadmins, the best manager is the manager you don't notice much, and the shit is just getting done.
All the original Agile was about was working in a piecemeal fashion, keeping management's dirt
Re:Like my boss always says (Score:5, Insightful)
No, but they can make a baby a month for 9 consecutive months. Increase the number of women a little and you can have a baby a month indefinitely.
Yes, but that involves waiting 9 months for the first baby. Our competitor already has a baby, so we need a baby now and I'm a manager which entitles me to behave like a spoilt 2 year old so don't give me any of that "I know biology" bullshit and get me a baby by the end of next week or I'll fire you and give the job to my nephew who says that we can have a baby in 7 days if we use Agile Procreation techniques.
9 months later: still no baby, but sprint 0.53.2 did produce a shaved rat embryo in a blue romper suit.
More seriously, producing one baby a month is routine production, and production lines work well for that. Producing software is almost always design and development, which is much harder to scale (of course, there must be a lot of creationists in management because even when they grudgingly accept that it takes 9 months to produce a baby, they still seem to think that the design and development should only take 7 days).
We're building a skyscraper with Agile (Score:2)
Re: (Score:2)
All I'm saying is that we can't develop something until we have a need for it, and has anyone really said they needed a second floor?
Re: (Score:2)