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.
... 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.
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.
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 !
He'd better work on proving that the corollary is wrong: "You can't produce a baby in a month by getting 9 women pregnant."
"National Security is the chief cause of national insecurity." - Celine's First Law
When Dice bought it.
Next!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
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.
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 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
we should build an OS above this concept
Then we can ruin it with systemd!
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia