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.
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.
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.
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.
True enough, but adding more men to the process near the end doesn't make her later!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun