HOME     SITEMAP     RSS     TWITTER     EMAIL    
Search:   

FollowSteph Follow Steph as he posts Blog Blazer Friday
 

Nine Woman Can't Have a Baby in One Month

Why is it that so many people continue to believe that software developers can do the impossible? In life there is always a critical path to everything, a path that you just can’t skip ahead. Yes sometimes work can be divided and thereby accelerated such as painting a room. You can get one person to paint four walls or you can get four people to pain one wall each speeding up the by four times. But if you want to apply two separate coats of paint you absolutely can’t get eight people to paint at the same time both coats. It just doesn’t work. The first coat of paint needs to dry before the second coat of paint can be applied. That’s a critical path you just can’t skip, no matter how much you wish it away.

However in software development a lot of people tend to forget this notion. There is a tendency to think that if we add extra developers to any effort we can shorten it by the amount of people we add. The thinking is if we add 20% more developers the time to implement the project should therefore decrease by 20%. The reality is that it doesn’t work this way. It’s not like painting a room. You can’t just grab a brush and start painting. It’s not that simple. Even if you’re the best developer in the world someone from the project still has to show you how to setup your environment. You have to learn how the software is implemented. You have to “get up to speed” which can take some time. This can take anywhere from a few weeks to several months depending on the project because of the inherent complexity of software development.

The Mythical Man Month

In some cases adding extra resources can even slow down your effort. For every person you add someone from your existing team needs to “bring them up to speed”, which means their not producing during this time. The closer you are to the deadline the more likely you are to slow the effort by adding new people to the team because of this training cost. They just won’t be productive quick enough to be worth it. They’ll probably only really start to get “up to speed” after the deadline.

My favorite analogy by far is the title of this entry, you can’t put nine woman together and expect them make a baby in one month. The critical path is nine months, no matter what you do. Some work just can’t be divided. Ever try to learn a language by dividing it up with several people while simultaneously skipping ahead some steps? And that’s what you have to anticipate with any software project. There will always be several critical paths.

Not only that, but sometimes one developer can implement a solution an order of magnitude faster and especially better than another developer . This is true in almost any profession. Just look at professional sports athletes, there is an amazing difference in quality. Can anyone beat Michael Jordan at basketball? Anyone want to play hockey against Wayne Gretzky? Every profession has it’s stars and its obvious that there is a difference among them, even among the elite of the elite.

Michael Jordan

The same is true with software and developers. I’ve heard sayings that an elite software developer can easily be worth ten junior developers. I completely agree. One Michael Jordan is worth several average players. Sometimes it’s worth waiting for a more qualified, or even just a specialized developer, to implement a solution. They might be able to do it in a way that will simplify the life of every other developer on the team and thereby reduce the total cost of the project today and tomorow rather than add to everyone’s effort. We’ve all seen patch jobs that take much longer to do anything with because of a bad implementation. That are buggy and needs to be continually fixed. That are just a complete mess. This is often the result of trying to push the critical path, of trying to apply two coats of paint at the same time.

Not only will you be ahead if you understand the critical path, it will also reduce your total software development costs. It will give you higher quality code which will lead to less bugs, less fixes, less workarounds, less hacks. It will lead to a better solution. Happier customers. Better maintainability. It will make improving and adding new features easier in the future. It will lead to higher employee morale. A better team. Lower turnover within the company. It’s just worth it. If you don’t believe me, just look at the statistics from this article on what happens if you push the critical path too much. Critical paths exist for a reason and it’s absolutely worth your time to acknowledge them rather than trying to wish them away.



 
Like this article?

Comments:

  •     Scott Meade
    · July 27th, 2007  · 12:31 am  · Permalink

    I agree that developer quality and productivity can differ by factor of 10. It’s interesting that you mention Jordan and Gretzky because the sports world is one of the few (music and acting being a couple other) professions in which participants value ‘practice’. Players and performers with dreams of getting to the majors know that their job doesn’t start at 9:00 or end at 5:00. Before the sun comes up and after dinner you’ll find them on the court, stage or performance hall continuing to practice, learn, and improve. Competition is fierce and participants love what they are doing, and so they have no problem spending hours daily getting better at what they do. So it should be with developers.

  •     Justin
    · July 27th, 2007  · 1:22 am  · Permalink

    Love the analogy!

  •     Magic
    · July 27th, 2007  · 3:49 pm  · Permalink

    I’d like to see Michael Jordan play 1 on 5…

    Quality is one thing, but sometimes you can’t do without quantity…

  •     Steph
    · July 27th, 2007  · 4:19 pm  · Permalink

    Hi Magic.

    I bet you if you took 5 regular people off the street who had played the game at least once in their lives (it sure feels like a lot of junior developers are like this) and had them play against Michael Jordan, he could take them on :)

    I used to play a lot of basketball in my hay day and I can tell you that 2 on 1 isn’t that hard with people who aren’t really that good. Even 3 on 1 is doable… I know I could never do 4 on 1 but I’m sure Jordan could.

    Maybe another good analogy would be the Mona Lisa. How many people could ever paint a Mona Lisa? Even if you had 10 junior painters working together they probably couldn’t do a Mona Lisa. As well it’s pretty much impossible to physically have 10 people working on the same painting at the same time, there’s just not enough physical space.

    I completely agree with you that sometimes you need quantity, no doubt about it. Its just that you can rush quality if that’s what you need. You can’t start building on your house until the foundation has dried. Somethings just need to take their time. And that’s a reality that’s very often missed by people trying to deal with software development.

  •     Steph
    · July 27th, 2007  · 4:28 pm  · Permalink

    Hi Scott,

    Absolutely. For me to get where I’m at, I spent a lot of time learning. I went to a 2-hour study group almost every week for almost 2 years when I lived in LA (a subset of lajug). There were some very smart people that attended that group let me tell you.

    I also read almost every book on software development on every aspect (from low level to high level). I tried to implement many things I learned (there’s nothing like firsthand experience). I listened to some really smart people and learned from them during my employment there. I observed, tried, and so on.

    And because of that I now know what I’m doing. Should I be compensated accordingly? That’s another completely different debate. But what I can tell you is that there is a difference between someone who has tried to educate themselves versus someone who’s trying to fly under the radar.

  •     Steph
    · July 27th, 2007  · 4:33 pm  · Permalink

    I just want to quickly point out that I’m not saying all junior developers can’t code as well as senior developers. Quite the opposite, I’ve also seen many “senior” developers who can’t code. What I mean by junior is people without the adequate skill sets. That is people who don’t have the experience or know-how doing what they shouldn’t be doing. For example someone who’s never written a line of sql designing a database. It happens more than you think!

    What I should be saying rather is that I’m finding this industry has a good number of people who shouldn’t be there. I’m sure it’s like that in many other industries, but for some reason it seems as though it’s easier to hide in software development.

  •     The Constructive Pessimist
    · September 26th, 2007  · 10:27 am  · Permalink

    [...] The destructive tendencies really come out if he is a manager or team lead: He’ll overrule requests for extra testing resources, he won’t manage scope creep in requirements, and he won’t recognize (or react to) the warning signs your project is headed for failure. This is also the guy who will throw extra people and overtime at the last minute on your failing project, optimistically thinking that nine women can make a baby in one month. [...]

  •     Give us nine women and we’ll have that baby out in a month « Skedsheet Blog
    · March 10th, 2009  · 10:30 am  · Permalink

    [...] a comment » I used to have a boss who’s favorite sarcastic expression was “Give us nine women and we’ll have that baby out in a month”.  He thought throwing people at a problem was silly, but I have proof it can work – up to [...]

  •     Chicken or Pig » Thoughts on a PMP
    · August 14th, 2009  · 10:10 pm  · Permalink

    [...] It’s provides some credibility with Senior Executives when explaining why you can’t have nine women create a baby in a month. [...]

  •     Software development misconceptions « Oscar Diaz Tech Entrepreneur
    · September 13th, 2010  · 12:02 pm  · Permalink

    [...] To read more follow this interesting link. http://www.followsteph.com/2007/07/26/nine-woman-cant-have-a-baby-in-one-month/ [...]

  •     Rhonda
    · February 15th, 2012  · 4:16 pm  · Permalink

    This is an interesting one-liner, but not much different than “Too many cooks spoil the soup,” though, which has been around a long long time.Leaving it as is, and accepting it as if it were a truism:Nine women can’t make a baby in one month.But it is important to keep in mind that
    Nine women could make nine babies in nine months.

    As with all catchphrases, something is left out:

    Nine women can’t make a baby at all unless one is a cross dresser.
    But given that nine women can make eight babies in nine months.

    And while nine women could make nine babies in nine months, given the right materiel, men can’t make a baby in any amount of time given any materiel.

    The moral of my post? Men that use the baby making capacities of women for slick catchphrases in a field dominated by men should think twice.

    Nine men couldn’t make nine babies

Write a reply:





 
FollowSteph RSS
FOLLOWSTEPH'S
RSS FEED!


SOFTWARE AND BOOKS BY STEPHANE GRENIER:

LandlordMax Property Management Software

LandlordMax is the EASIEST
Property Management
Software available!
Try it for free!

Real Estate Pigeon

Real Estate Pigeon
The place to ask and answer
all your real estate questions

Blog Blazers: 40 Top Bloggers Share Their Secrets to Creating a High-Profile, High-Traffic, and High-Profit Blog!

Blog Blazers is a book that
features secrets from the
Top 40 Bloggers on the web

How to Generate Traffic to Your Website ebook

How to Generate Traffic to
Your Website
is an ebook for
to you achieve success


 

FollowSteph
More resources from Stephane Grenier:
PUBLICATIONS
For people who work on the web
Blog Blazers
How to Generate Traffic to Your Website
 
SOFTWARE
The EASIEST Property Management Software available!
LandlordMax


Copyright @2003-2013
LandlordMax Property Management Software

Disclaimer: This is a personal blog about my thoughts, experiences and ideas. The contents of this blog are for informational purposes only. No content should be construed as financial, business, personal, or any other type of advice. Commenters, advertisers and linked sites are entirely responsible for their own content and do not represent the views of myself. All decisions involve risks and results are not guaranteed. Always do your own research, due diligence, and consult your own professional advisors before making any decision. This blog (including myself) assumes no liability with regard to results based on use of information from this blog. If this blog contains any errors, misrepresentations, or omissions, please contact me or leave a comment to have the content corrected.