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