This is the first article in my myth busting series where the conclusion is not mine. In fact, the above sentence originates from the book called "Mythical Man Month" published in the early 1970. You can find a screenshot of the book's cover below if you're interested in looking it up.
The book is full of controversial statements, almost impossible to believe in, such as the following ...
One dev can do in one month what two devs can do in two months
Implying the time2market requirements for a project increases exponentially every time you double your resources. One of my favourite questions in the book is the following.
If one woman can have a baby in 9 months, how fast can TWO women have a baby?
Once phrased such as the above, the truth becomes painfully obvious I presume.
How we do stuff
At Aista we've tried our best to follow the lessons the book teaches. Currently there are 4 people working for Aista; Mohsen is operating and developing our Kubernetes clusters, Shirin is our primary frontend developer, I am our primary middleware and Hyperlambda developer, and Mo is a little bit all over the place, in addition to creating amazing designs, and QA testing, etc.
1st of December 2021 we started for real. 15th of August the project is fundamentally done. 9 months from start to finish, and we've got one girl on our team. The irony isn't lost on me.
When fast becomes slow
I told my partner about the Mythical Man Month yesterday, and the way I typically explain it is to imagine you've got one ton of "stuff" you want to move from A to B. If it takes one man 7 days to move your stuff, obviously it can be done in 1 day if you hire 7 people. This is what our intuition tells us about resource management, and hence most of us tends to throw more people at the task at hand to solve it faster. However, with software development such ideas fundamentally breaks down and no longer applies.
The reason is that software development is a cognitive job, requiring communication, collaboration, planning, and orchestration. Hence, the more people you add to the same project, the more "project overhead" you acquire, until you reach the point where nothing can be done, because your employees spends all their time simply planning how to do things, to avoid messing up somebody else's job as a consequence of doing their own job. This was what I was hinting at with yesterday's article here at DEV, where I proclaimed that Agile is mostly rubbish. Jeff Bezos has a "two pizza rule" which goes as follows.
A software development team should always be possible to comfortably feed on two pizzas
If he can't feed the entire team with only two pizzas, his team is too big. This results in teams with 3 to 5 people max. 5 people is kind of stretching it if you ask me, but OK, I think the ideas of two pizzas is easily understood and conveyed, and I can agree with it.
Don't be tempted to hiring more people
If you've got a software development project, and it is late, please do not be tempted to hiring more people. This will not make the project proceed faster, quite the contrary in fact, the only thing you'll accomplish is to make it slower. This is fundamentally difficult to believe in, but has been proven hundreds of times since the 1970s when Brook wrote about the idea originally. Below is the exact phrasing of Brook's words.
Adding more devs to an already late project only makes it later
Top comments (11)
Great article.
That's always possibly true, but it's especially true if you have multiple devs that are individually very good, very opinionated and who love to argue. And oh boy do developers love to argue!
At a previous job the front-end team was stuck for two or three weeks because there were passionate debates on how TypeScript imports should be ordered. PRs could not be merged before this was resolved because each one was reverting the imports in the "right" order. I'm not a front-end dev myself, so if someone knows why that's important, I would love to get to the bottom of this, even if it takes one month of hard work.
Hahahahaha :D
Some things are too important to be debated comes to mind ... ;)
Edit - Define "good". A big motivation for me with these articles is to redefine the meaning of the word "good developer". Today unfortunately, it's abused, and misunderstood, such that the dev that knows the most complex theory is perceived as "the best" - While often the exact opposite is true, as in the more pragmatic developer is better for all practical concerns. I once spent two hours quarrelling with a colleague over UTC best practices. Interestingly, we were mostly in agreement, something I tried to emphasise (in vain) to get out of the fight. However, he was persistent, and refused to stop shouting, until I showed him a Jon Skeet blog where my argument originated from.
Objective this guy was better than me. However, I created in 30 minutes what he failed to create in 4.5 months. Yet again, define "good" ... :/
That's a great question.
I would differentiate solo projects and working in a team.
For solo projects, do whatever makes you happy and productive.
Want to program in Haskell? Go for it.
When working in a team, I wish we had something like the Serenity Prayer
A nice article with so many valuable points.
Thx Andrew 😊
Nonsense, if you get good people development will be faster, usually people who code completely alone suck at coding because they never learned to work in a team well .. if you can't manage a team with 10 people you are just not a good team leader.
Linus Torvalds made git alone. Just sayin' ...
... but he probably "sux", right ...? ;)
if you compare 99% of the people with Linux Torvalds you make a huge logical mistake
even bigger nonsense
Bring it up with Jeff Bezos, I'm sure he wants to hear your objections ... ;)
Just google many have objections to him a good team consists of 5-12 people, they will be very hungry with two pizzas