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.
says the snake oil salesman. Big surprise :-)
Someone selling consultancy and services in DevOps saying you can have your cake and eat it too.
From reading the article, microservices solve the team size coordination problem. Good luck with that on the real world.
Thinking that microservices is a silver bullet.
This idea surfaces every now and then. It certainly has its uses and no doubt there are scenarios where you can beat the mythical man month.
A rookie mistake is not checking that my email has a 10 minute lifespan. This PDF seems to be a IT Automation sales pitch. Joe promptly emailed me.
Hi ,
Thanks for your interest in the 2015 State of DevOps Report. You can access it at any time here.
Did you know that automation plays a vital part in building DevOps culture practices? Using IT automation software, like Puppet Enterprise, you can ensure consistency of environments (dev, test, prod) to support continuous delivery. Learn how Puppet Enterprise can help you build DevOps culture and practices.
Thanks,
Joe Henderson
Puppet Labs, Inc.
308 SW 2nd Ave., 5th Floor
Portland, OR 97204
USA
503-575-9784
joe.henderson@puppetlabs.com
Manage your emails or unsubscribe.
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.
9 women can't make a baby in a month
Microservices may help parallelisation in one are, where the services are implemented. Designing and specifying the services and interfaces, then integrating and testing will have a complexity overhead. Also coordinating fixes and releases over a large number of developers will take longer. In most projects the advantage will be limited.
Remember when the mythical man month was written a microservice-like architecture of text based systems using lots of discreet Linux programs and pipes was quite common and heralded as a way of splitting down a system and allowing parallel development, so the concept was probably know to the author.
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 !
Plus the bloody "state-of-the-art" report is nothing more that a few bullet points with a form for collecting personal information. Lamest click-bait ever.
Please?
The latest report from my organization (please click on all the links and give me loads of personal information to sell) has disproved mythical woman month. The original myth holds that you can not get nine women pregnant and get a baby in one month. The absolutely latest and greatest agile methodology with Kanban technology and our copyrighted and patented bullshittology technique has totally disproved that theory. Come one, click, gimme my money. What are you waiting for?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...when nine women cooperated to make a baby in a single month.
DevOps FTW!
Never bet against the laws of thermodynamics or Fred Brooks.
Watch this Heartland Institute video
Hold up stuff on the critical path and it doesn't matter about the rest. Anyway, projects are always underestimated. Who's zooming who said the lady in the pink caddy.
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."
F*** Agile and all of it's cultist followers. It's nothing but a pointy-haired management scheme to avoid any sort of requirements gathering and to micromanage the s*** out of devs. I hope the people who came up with it and their "manifesto" burn in hell.
The common sense suggests that this entirely depends on the project under question. Say if there are five independent tasks each taking a month for a team of five, then a team of 25 will complete it in one month. On the other hand a woman "produces" a baby in 9 months but 9 women can't "produce" a baby in one month.
Everything in the summary was fine until the point I've read "agile".
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.
This is just another example of someone/something claiming to be smarter/better than what came before.
And what exactly are the odds of THAT? Think about that - what are the odds coming up with a "new way of doing things" improves things outside of the specific problem it was developed to address?
Which is why EVERY claim of "This is WAAAY better!" is almost certainly bullshit.
Especially when an asinine fucking buzzword like "agile" is used.
I think it's the same premise, but inverted. Management thinks the project will be finished faster if adding more man-power, but actually the inverse happens, it will be finished even later.
A logical fallacy is not taking into account the complexity of a task. If one woman makes a baby in 9 months, 9 women should be able to make a baby in 1 month.
Comparing DevOps to Development is probably the issue. You can surely throw more warm bodies at DevOps tasks and get faster turn-around; it's not a creative profession doing creative or analytical tasks, but a trade doing mechanical tasks.
And he's figured out a way for 9 women to have a baby in 1 month too!
You can't just speed up development teams by adding more team members.
But the devops / microservices do help you to create an culture / architecture where you get more but smaller parts each with their own team.
Thus you'd have more teams.
So the project as a whole can might go faster if you can chop your software up in different pieces without any interdependence (which obviously doesn't always apply to all problems).
New things are always on the horizon
This post has a lot in common with a 10 pound sack of crap --- and it's not the outside sack-like goodnes but the contents!
Perhaps Wallgren should read the Mythical Man Month?
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".
So far we're on the third sprint and we have a desk in a steel frame with a planter on top and a hot-dog cart to the side.
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.
Sounds like you have it basically figured out. You keep the corporate politics BS from interfering, and I'll deliver an effective, reliable solution quickly.
> 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)
I don't know, an average developer can produce quite a bit of technical debt very quickly. That's productivity, right? :)
Message me when you're hiring.
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.
In other words, divide-and-conquer meets software project management. That is how it has been done to deal with these issues, for a long time before micro-services. And microservices would not help if the project, the totality of the project is late. The issues related to MMM's postulates are, for the most part, technology agnostic.
And in fact, the fundamental problems are not technology-based, but organizational/political ones. I love microservices, but they are, in the great scheme of things, a technical detail. No amount of technical silver bullet will help subvert organizational/political forces.
We do this now - we have multiple largely unrelated projects that we can work on in parallel.
In this case so long as you have few resource allocation problems and staff can do their own job you can add staff and accelerate.
The first book on the subject was titled "The mythical man-month"!!!
The same way the waterfall model had always been a counter- example.
"discovering" that those models are worse than your current faddish methodology is like finding that your new "locomotion revolution" beats square wheels.
Get off my lawn.
You're not old until regret takes the place of your dreams.
Exactly. I have seen development methodologies come and go. The one thing they all have in common is that they are created for and marketed to the management. Because management is not good at, well, managing, development methodologies give them things that they can see and touch and thus believe that progress is being made. Meanwhile, every single development methodology has aspects that do not fit how development actually happens, and as such, time is wasted trying to fit how real life works into the development methodology. I have been at two different companies that used Agile. At one, I never heard the words "scrum" or "sprint" or "stand-ups". At the other I did, but the developers computers were locked down so that participation in the stand ups was difficult.
Agile, to me, almost looks like a caricature of a development methodology. It is almost like Scientology, where L. Ron Hubbard made a bet that he could create a new religion and gullible idiots would eat it up.
If you are not allowed to question your government then the government has answered your question.
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.
Nothing scales linearly, but some things scale more linearly than others.
If you are not allowed to question your government then the government has answered your question.
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.
"if you can see it, it's nonlinear".
Having managed projects ranging from R&D, defense systems, construction, and software development.. the MMM is all about work teams. Most successful project managers learn this sort of thing from experience (read pain and failure). Everybody thinks they have some sort of 'new concept' that is the magic bullet to 'solve software development problems'.
Forgetting that the one common element is... people. No matter WHAT methodology you claim to follow, I guarantee at least half of your team will think it's bullshit, and begrudge the paperwork that is getting in their way of just getting the job done.. THEIR WAY.
The best thing a good manager does is remove restraints and barriers, and filter bullshit. And let the team gel and get their shit done.
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
Or as my company likes to do. Lay off 4 people and tell the 1 remaining he still needs to do the 5 month project in 1 month.
Vermifax
Logout
... what you think it does.
If we assume the OP is taking a very "hard" interpretation of The MMM, perhaps something like "Man Months can NEVER be interchanged". Then if the OP has an example where they can trade manpower for months -- in that case, they would have a counter example. Which would disprove "never".
But I can't honestly believe the OP thinks the proper interpretation of The MMM is "Man Months can NEVER be interchanged". So either the OP is being willfully obtuse, or they need to actually READ The MMM.
Even as an agile supporter, I have to call bullshit on this clown. Adopting agile is meant to decrease process overhead and add practices meant to improve code quality. It does not do anything to reduce complexity itself or the burden of coordination (aside from reducing process overhead).
Could get it done in less than a second!
Perhaps some projects can be broken down into component, but there is a point that they can't anymore. If it takes 5 people 5 months, then perhaps 25 people can get it done in 1 month. But there are limits. I don't think anyone who has ever worked on a project believes that you can then put 750 people on most projects and get them done in a day. Sure, its possible if the task is trivial, but most aren't.
Ninjas don't carry tic tacs
Huzzah! It seems a "Silver Bullet" has been found in DevOps.
https://en.wikipedia.org/wiki/No_Silver_Bullet
The company I work for, who is late to everything, is now starting to get the Agile religion and is trying to apply it to systems work. (Yes, DevOps.) My honest opinion, having really given it a try, is that Agile is designed for the lowest common denominator engineering teams. Everything has to be broken up into small enough tasks that no one takes on too much, and sometimes more time is spent planning than actual working on stuff, forcing tasks to fit into this model. It's perfect if you are a big offshoring shop and are performing run of the mill development tasks that don't involve any business understanding. It's a whole lot easier to say "code me this service with these interfaces in 2 weeks, don't worry about the rest of the project" than to get developers thinking about the bigger picture.
It seems like Agile and DevOps culture was designed for this kind of "we add developers at web scale" approach to development. If you're doing something that's more complex than the back end for a phone app, that's where it can break down. With Agile you _can_ split tasks up such that no one developer knows anything beyond their own little piece, but that doesn't scale because you can't quickly train new guys in a codebase or operational environment without any context.
I know the link is to Puppet Labs, but it reads more like Muppet Labs. Doctor Bunsen Honeydew here.
Contribute to civilization: ari.aynrand.org/donate
If you split one big project into five smaller projects,
You will need someone to select the split points and manage the communications between the sub-projects. And when each is done, you'll have to integrate them and test the assembly. Not that this is necessarily bad. But that mangement layer adds complexity and overhead. Agile might work well in an environment where the sub-projects are just teams sitting in adjacent cubicles, working in the same organization. Where interface problems can be solved by grabbing a few people, finding a conference room with a white board and working things out. But not so well if the inter-project communications involves customer/vendor contractual negotiations. And management starts to get it's panties in a bunch over change orders.
In my experience, management is often selected based on the Dilbert Principle. Not the sort of people you want sitting at the nexus of the critical communications path between groups trying to get actual work done. Not to be totally down on Agile, it does formalize the inter-group communications, giving the PHBs well defined documents to rubber stamp and otherwise restricting their ability to invent new processes on the fly.
Have gnu, will travel.
Microservices have nothing to with the mythical man month. As quoted "If 5 developers.... can't be reduced by 25..." If using microservices that means that original 5 may mean you can support 10, 15, etc. so that is the baseline number if you have 10 developers where 9 work on their own service with one providing the infrastructure for communication, trying to add 10 more will not make the project complete faster.
Or both?
Please provide more information about your Agile Procreation techniques.
How did they randomize the subjects? They also first picked the subjects before selecting the hypothesis which I find odd. Did they skew the hypothesis to meet the population?
What is the definition of DevOps? How cvan you discriminate between DevOps and no DevOps environments? I assume it is a spectrum, how is that controlled? What was the control in the study?
putting the 'B' in LGBTQ+
The amount of methodology and process necessary to complete a project is inversely proportional to the competency of the team members doing the work. Outsource to save money on coders, pay for it in process consultants, project managers and meetings. It is the great equalizer.
Take a project that would take one developer one month, assign 10,000 developers to it and see if it is completed instantly.
Just one simple issue reverses the ignorant "reversal" touted above: A team of 5 five people who have to maintain bilateral, substantive communications with 4 others, has a total of 20 paths of dialog to maintain, so the project can be completed in five months..
For a team of 25, there are 25*24 paths: A total of 600. And, only one month.
So, FIRST, you have 5 programmers with 20 total dialogs going on, and it endures for five months. The alternative offered is 25 programmers with 600 paths of communication, and it all has to be done one month. When do you do YOUR thinking?
If you can't see the fallacy in that comparison, you are a typical, incompetent "business manager" who's can't write the BASIC program to print "Hello, World".
Fred's empirical observation still stands, to this day.
After decades of this we just never seem to learn. There is always some sort of magic snake oil that can be poured on the process to produce perpetual motion. Sigh... so many wonderful ideas. Bottom line, though, is that the more people involved the slower things go (the communications factor...a game of telephone) and add the 'I want the return code to be an ebcdic negative string' as opposed to what the function really returns... so this piece of the standard library needs to be redone. etc... The magic factor is not snake oil greasing those unicorn horns... it is the skill and experience of the folks doing the work. And no matter what the methodology, four dolts will not produce the work of one genius. And when management wants that baby in one month... they also reserve the right to change the specs without any impact on the delivery schedule. And what is worse... its not just coding that is subject to these silly yet fatal issues.
If the project is the equivalent of moving dirt from pile A to pile B then then many hands make light work until it gets to a point where people are just getting in each other's way. So 20 might be 4 times better than 5 but 1,000 is just a huge waste of resources as maybe 950 would be best kept out of the way.
Then there is the statistical genius issue. If you have one good programmer trying to solve a horrific problem then two or so programmers might allow for some interesting insights that one might not have. But this sort of hits a rate of diminishing returns in that the average programmer isn't that much smarter than any other programmer. Thus 10 might not be much better than 2. Except that if you have 1,000 programmers the simple probability is that one of them is a genius and thus the program might be solved more than 1000 times faster than a single programmer or more realistically it may have never been solved by a handful of programmers, ever.
Then there are the classic programs where people try to architect it into wonderfully separate abstract sections where individual programmers or small groups can work on each piece. This might sound good in reality but all projects have a certain amount of spaghetti to them and thus their reaches a point where each new programmer isn't able to hive off a part very easily without excessive communications with other programmers and thus not really help that much. This is a fairly typical corporate project flow and thus the Mythical Man month does apply to many projects, just not all projects.
The thing is, many of these split points are becoming well-defined. Authentication? Just use OpenID Connect. Federated memory cache? Just use memcached. Need a database? Use an ORM that will speak to anything through JDBC, ODBC, PDO, or DBI and hides all the intricacies, then let your DevOps folks and DBAs handle those stock apps as infrastructure. Let the developers focus on the business value.
This works quite well when you're developing yet another web app. It's not the same as developing a new mainframe and its OS that just happens to need to be backwards compatible with two previous generations of mainframes from an application level and offer new features like VMs, virtual I/O, etc. like the 360.
The single best methodology I ever used was R.U.P. from IBM.
It identified and placed high risk first.
It had a set of shared documents which the team actually used since they made sense and were useful.
It had time boxes and naturally supported controlling scope creep.
We never had a late project. And we identified two projects as impossible in the 1st stage before a lot of work was done.
It was a lovely and successful methodology to work with.
On the article. BigO time for debugging is exponential. You really can't change that. If you do twice as much work in the same time period by whatever method, debugging will take 4 times as long.
We had an agile group for a project. It was very expensive. It delivered a product that only functioned well in the development environment. This was partially political and a lot of arrogance. We TOLD them the customers wouldn't pay for that level of environment but they thought the customers would comply. It wasn't a horrible process and they kept their scrums to 15 minutes every morning. The entire project relied on a new, risky technology which was discontinued by the provider (Adobe) about 2 months after the 30 million dollar project was completed (so then they had to drop millions more redeveloping it in HTML5).
From what I saw, agile did not protect from scope creep and it had problems with chunks that difficult to decompose enough to fit in one build cycle.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
This works quite well when you're developing yet another web app.
Right. But that's a very small slice of the software development space. Lots of embedded applicatione don't even have the luxury of a real O/S. On the other hand, even with web apps (well designed ones) most of the interesting work is done by the time you get to where you can fling a few buzzwords at the APIs.
Have gnu, will travel.
All large projects should be modularized in general, if for no other reason than to maintain the sanity of people. Microservices are slapping a remote interface onto a module. In Java, a little clever use of interfaces and dependency injection, and a "microservice" can be remote or local with almost no change to client code (think proxy pattern). There is change to client configuration due to local needing data store connection information and remote needing remote discovery information.
You could divide teams along these modules, but I find that causes a lot of coordination overhead. I like dividing teams along lines of delivering end user visible features and they work on whatever module is necessary. It helps to reduce the temptation to write the same thing 3 or 4 times in slightly different ways because no one wants to go through the effort required to convince some one else to put that in their module. I generally try to have teams work in the same area for a long period of time which means they usually don't have to be experts in every module, but instead a few that are core to their area, know a few that are peripheral, and have a passing understanding of the rest. It does require good test driven development, continuous integration, teams that will fix whatever regression they cause, and teams that respect other teams enough to "do unto others..." and write comprehensible and testable code.
As for deciding what your modules are... That depends. It can evolve, but it requires some one to pay attention to what is being developed and realize when new responsibilities are showing up that belong in a new module. Hopefully, many team members learn to recognize and raise modularization opportunities. I like the Domain Driven Design approach as a starting point, but that it has quite a bit of overhead that would not be appropriate for some software.
Sweet. So you still aren't trying to make a human baby every month, you're saying "a team of rats could do this software task just as well" and trying to make 9 rats instead of 1 baby. This obviously only applies to problems that can be solved with rats.
I know that this is a true-Scotsman type of argument, but this only proves does not necessarily disprove the hypothetical man-month argument is wrong. It proves that either hypothetical man-month argument is wrong or DevOps are not development projects (this is the more likely scenario). While it may seem like problems are fixed faster in DevOps vs SDLC, the reality is that it forces all users to be perpetual alpha testers (that's right... not beta testers... alpha). DevOps is why a cell phone bought 3 years ago cannot function anymore unless you upgrade it and slowly cede more and more control over your private info to be data mined. It makes devices less and less programmed and more and more terminals to data centers. And if the devices are not programmed, then the process which maintains them is not a development process. The most successful end-user operating system of all time is Windows XP. Except it's not. All XP machines are perpetually upgraded. It's why MS has decided that Win 10 will be last update of the operating system. After that there will only be upgrades... perpetual alpha. The truth is that it only worked because it had a solid foundation in the NT kernel. No amount of DevOps scale out could have created that.
The mythical man month was a declaration that software which can continue to work without updates for 20 years cannot be made faster by throwing more people to plaster band-aids on it as it bleeds faster. DevOps, as a permanent fixture, is only a few years old and it only appeals to millennials who think that multitasking (as opposed to deep thinking) is a merit. The fundamental structural problems that find their way into the system and can one day bring it down will necessarily be missed. Band-aids only work for so long.
Any guest worker system is indistinguishable from indentured servitude.
Well, DevOps is the only way to make any use of millennials. It's geared towards people who cannot work on the same task for 3 days, let alone 3 months.
Any guest worker system is indistinguishable from indentured servitude.
Sweary Sherlock Holmes. If that's not a Viz character it should be.
This is my point. It works very well for a well-defined, well-understood, practically standardized stack to be used to write a new application. That's not the same thing as breaking new ground on a project without all that supporting code and voluminous standards documents already helping you out. The Mythical Man Month hasn't been disproven at all. It's just that in some areas it's possible to change the scope of the project. Smaller projects don't take as long.
You're very close to how I'd word it with babies. See, if you want one baby you wait 9 months. If you want 5 babies and you have one mother, you wait 55 or 60 months. If you want five babies in 9 months, you can totally have five mothers. You can't get one full-term baby any faster than 9 months by adding mothers. DevOps doesn't solve the one baby problem any faster nor the five babies by one mother problem any faster. It can solve the five babies problem if you're okay with the babies having different mothers (team leads or sub-project managers) and different DNA (team implementation styles). If the other parent (the overall project lead or the solution architect) is the same, the five babies may learn to live together as a family, although there's the possibility they won't.
Where I come from, we call that a "cluster f*ck". You know where 20 people are tying to work on the same industrial vehicle at once.. Versus when 3 guys do their part, then the hoses, then electricians, and so on. Each taking turns.