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.
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.
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.
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
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?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
$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 better now than they were when we first bought JIRA.
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."
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.
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".