Slashdot Mirror
Disproving the Mythical Man-Month With DevOps
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.
Love the smell of coffee plus bullshit in the morning.
... 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.
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.
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.
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/...
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 !
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.
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.
-- "Simplicity is prerequisite for reliability." --Dijkstra
Submitted by StewBeans and posted by samzenpus. A link to enterprisersproject.com.
The only logical conclusion is that some fucker is selling something.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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 dirty hands away from twiddling requirements mid-process, and emphasizing the sad truth that at a software project's inception, you can't really say how it's going to ultimately work, what the customer REALLY wants, and thus cannot reliably design it in one big go and implement it in another. That's fucking it. Anything else on top is a snake oil sale.
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).
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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 supporters to ensure conceptual integrity.
Perhaps you should read it? I recommend that all engineers read it every few years. I have read it a few times in my career and various points stick out each time.
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
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".
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.
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.
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.
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, and also coined the term FUD (fear, uncertainty, doubt), which is popular, and well understood on Slashdot
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
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...
-Chris