
One woman can’t have a baby in nine months (2007) - luu
http://gigamonkeys.wordpress.com/2007/05/10/baby-in-nine-months/
======
kabdib
You're not debugging hard problems all the way through the whole project. The
cool, hard bugs happen maybe two thirds of the way to the ship date.

Now, imagine puffing up your development staff by a conservative factor of
two. Assuming perfect skill transfer you're going to shave maybe six weeks off
the schedule? In practice, no way. Your 'expert' devs are going to be swamped
for a week or two while the new guys are coming up to speed.

This begs the question: What's magic about nine months? I've worked on
projects that have practically killed their teams and hit their ship dates,
and the result was ALWAYS that the product sucked pretty bad, and the team
wound up doing another 3-4 month "fix" cycle that (a) dramatically improved
the product, and (b) didn't matter, because the damage had been done and the
product was toast. Then there was team burnout and churn. All very bad damage.

If you are trying to compress ship time by adding engineers you're already
making mistakes that will probably kill your product. The right thing to do is
to slip, and slip significantly.

I know: "We have to hit Christmas!" \-- or whatever classic date your industry
needs. But shipping a crap product in November is usually FAR worse than
shipping a good product three months later.

~~~
ryandrake
Everywhere I have worked as a developer, hitting the date was far, far more
important to the "folks upstairs" than quality. As mabbo mentioned, it could
be inter-project dependencies. What if your software project is a driver for
your company's electronic device, and they're ramping up for production in a
month? You can't just say "Hey, the software team shouldn't be date-driven.
Just keep 5 million finished units in a warehouse until the driver is really
ready!"

It could be needing to ship in time for Christmas. You mock it, but the
difference in terms of sales between hitting and missing Christmas can be the
end of a small shop. Same goes for hitting trade shows. You can't just call up
CES and tell them you need another week and could they please move their
conference date.

It could be that your contract states that something will be delivered on
DATE_A, and then something else on DATE_B. Dates are easy to describe and put
in contracts. Quality goals are a lot harder to articulate and translate into
terms of a contract. You'll see rough quality goals in some contracts, but
you'll see dates in them all.

Saying, "We'll ship when it's good enough" often means you're never shipping.
Go find products whose ship date was "when it's done" and look how late they
were. When you aim for a date, and everyone is taking it seriously, you might
just be able to ship something on that date, and "something" is usually good
enough.

~~~
mpyne
> Go find products whose ship date was "when it's done" and look how late they
> were.

Many of the best Nintendo games were delivered under this rule (as in yes,
they actually shipped), and went on to be incredibly successful.

You're right overall, of course, and we can't all be Nintendo. But for some
markets quality really is important, and in those situations you can't
shortchange. You have to decide based on what your own unique situation in the
marketplace is.

------
kenjackson
The author also misses a key point is that in pregnancy there are no shared
resources -- each pregnancy is independent. In debugging hard problems this is
often NOT the case.

For example, if you put 100 teams to find a particular issue that is causing
crashes in the field you suddenly have your field team getting requests at
random times asking similar questions, although each may have a distinct
twist. At some point in time a percentage of the team suspects the networking
stack -- the networking team starts getting questions staggered over time.
Their time now gets spent looking at this. And then if you have to run some
type of stress or in a specific customer environment -- that gets
sequentialized, unless you buy new hardware.

And lets say all 100 teams find a fix, but they are all in different places in
code. Now you have to figure out which is the right fix, which may not be a
complete sequential process, but it's not embarrassingly parallel.

On the flip side, if you only want one fix, it's easy to shelve the rest (you
could pull one of the other fixes back in if the select fix is found to
regress something else). But if you only want one baby, and multiple couples
have one, it's a bit trickier to figure out what to do.

~~~
bane
The good news is that pregnancy is almost an embarrassingly parallel problem.
This gets reflected in polygynous societies and the occasional episode of
Sliders.

[http://sliders.wikia.com/wiki/Love_Gods](http://sliders.wikia.com/wiki/Love_Gods)

------
al2o3cr
Two thoughts:

* you only get to combine probabilities that way if the individual trials are independent. Debugging does not usually work that way - if I'm looking for the same bug as you, I'm likely to try many of the same things. Unless, of course, your development team is using a stochastic debugging process, in which case you've got... other problems.

* I read the analogy as more about the challenges of inherently-serial processes (must complete A and B before C) and the individualized nature of software creation. For a counterexample, note that other "building" processes are parallelizable and standardized; it takes quite a long time to turn bauxite, sand, and rubber into a car, but the intermediate steps are not specific to the final product.

------
cgriswald
There's a problem with his argument he doesn't really address. The baby
analogy isn't perfect because having a baby is a physical process with a set
success rate. So the math checks out, but debugging isn't a physical process.
Debugging is problem solving.

When debugging there is likely to be a lot of overlap in the ideas and methods
the individual debuggers use in order to find the bugs. Obviously, the
debuggers can communicate with each other about what doesn't work so there are
gains there. But in terms of thought processes, there will exist this overlap.
It is only in the places where there is no overlap that an extra debugger is
useful. And as more debuggers are added, the odds that any additional debugger
will provide independent thought is diminished.

His model is too simple because it does not account for this overlap.

~~~
JoeAltmaier
Id go further. The best debuggers don't look for the bug; they look to prove
what Can't be the problem, reducing the search space geometrically. With
parallel debugging efforts, many of the debuggers will be pointlessly crawling
through code and tests that have already been discounted.

In my experience hard bugs don't get solved until a skilled debugger is found
to look for them. Up til then little or nothing gets done. And skilled
debuggers are small in number, and their efforts are necessarily serialized.

~~~
malisper
I believe you are missing the point he is trying to make. With parallel
debugging a lot of the time will be spent looking through code that has
already been checked (more women can't have a single baby in less than nine
months). The only thing that changes is the expected amount of time it will
take to find the bug (with more women there is a higher chance of having _a_
baby in nine months).

Even if you do have the best debuggers, they can still miss the bug. By
throwing more debuggers at the problem, there is a higher chance the bug will
be found in a given time frame.

------
JoeAltmaier
Carry a baby, not conceive a baby. OP (deliberately) misinterpreted the meme
for comic effect.

------
wisty
Apple does this, I think. I wouldn't be surprised if Amazon did (in their
quest to reduce everything to replaceable cogs).

You create three teams, and get them to work on basically the same problem.
Apple will often give them slightly different scope (port OSX to the iPhone,
add functionality to the iPod OS, see which project can ship first / deliver
the best product).

Problem solving is more or less lognormal. You can squash a trivial bug in
minutes or weeks, depending on whether or not you spot the cause of it. This
can actually save man hours - as you don't have someone staring at stack dumps
for weeks without making any progress whatsoever - you just tell them on the
second day that a co-worker found the error, and ask if they can think of any
other things that might be wrong (now that they've got the provisional fix).

I can see a lot of comments worrying about the efficiency of this - what if
two people solve the problem at the same time? What if the quick fix isn't a
good? Well, that's a good problem to have - one engineer / team didn't really
fix it, and one did - you've just saved yourself from the risk of missing the
root cause!

Yes, there might be a few painful meetings, especially when two different
approaches have been shown to work. If patching the iPod OS and porting OSX
both seem to work, it's going to cause an ugly political showdown. But it
would be more political if neither team had written a line of code, and were
simply duelling with Powerpoint (Keynote?) presentations to back up the
viability of their approach.

------
arthurjj
The argument he makes about increasing your chances of having one successful
project by funding lots of projects is similar to the VC idea of investing in
many companies in the hope that one pays off.

While interesting Mythical Man Month's use of the metaphor always seemed to me
to be saying that the non-parallelizable tasks take up the majority of the
development time. Which is a different argument

~~~
icegreentea
Yeah, but one thing that often gets overlooked when talking about 'non-
parallelizable tasks' is that most tasks aren't actually non-parallelizable,
rather that they are weakly parallelizable (less than linear speed-up), or
they have a large time constant (the 'train-up' time of adding additional
resources). If you can identify this and recognize your current position, it
can still be possible to accelerate your timelines by adding more people in
some cases.

~~~
HCIdivision17
Can we say courting is the equivalent of the 'train-up' period for having a
baby?

~~~
JoeAltmaier
Definitely THAT can be parallelized. Just play the field!

~~~
adwn
But make sure that you have proper isolation between the subtasks.

------
FollowSteph3
The best part of the analogy is that most of the work is post birth. That is
maintenance and care of the baby, just like with software ;)

~~~
zachrose
Exactly. If your software is only going to be used more than once, then any
notion of "finished" is illusory and often toxic.

------
btown
The article's conclusion seems to be that even if debugging/software
development can't be parallelized perfectly (which is true because debugging
requires a buildup of mental context about a codebase), since the amount of
time required is a random variable, doing the entire task redundantly in
parallel will necessarily reduce the expected value of the minimum amount of
time required. For instance, if you throw $n$ developers with equal knowledge
of a codebase independently at a problem whose time-to-solve is exponentially
distributed with rate $\lambda$, then they'll solve it at a rate of $n
\lambda$. Of course, this is almost always less efficient than letting them
work on their own problems!

However, if you apply a similar analogy to _reliability_ instead of time,
having people work on the same task with what would appear at first to be
redundant effort can increase reliability phenomenally. In a way, we see this
in organizations that demarcate developers and test engineers - you're
throwing bodies at a problem, creating a rivalry of two groups that challenge
each other by attacking a problem from different angles, and in doing so you
have a different distribution over the error/bug rate than you would
otherwise.

An interesting read on this point is [http://www.fastcompany.com/28121/they-
write-right-stuff](http://www.fastcompany.com/28121/they-write-right-stuff)
about the team that does (did :( ) software engineering for the space shuttle.
Things like rigorous separation into development and testing sub-
organizations... duplication of coding effort insofar as every line of code
isn't just code-reviewed, but requires double-entry in a specification as
well, and review of that specification... constant "process-ization" of
debugging insights so the entire team doesn't make the mistake again. It's the
exact opposite of "agile," but it makes sense if reliability is what you want
to model and optimize.

~~~
mpyne
> It's the exact opposite of "agile," but it makes sense if reliability is
> what you want to model and optimize.

One of the more interesting aspects about that classic story was that the
software developers, despite having deadlines of their own and having to adapt
to ever-changing hardware on the Space Shuttle, almost never ended up in
"crunch mode".

------
drakaal
The author takes the analogy beyond the logical conclusion.

The saying is simply meant to say "there are things that you can't make happen
faster than one person can do them".

There are corollaries that we used at Microsoft. "And you can't assign the
baby to a man" and "She can't have it all on her own."

Taking the analogy farther than one should... Conception is typically a two
person activity. But assuming you have a Fertile woman, you can take that 15%
that they talk about and up it significantly by trying with 3 different men a
day, every day of the month.

So you can "have the baby in 10 months" with enough planning and since you
only need each guy for about 5 minutes, you only added 450 Minutes (about 8
man hours) to the process. Less if you stick to 20 days conception can happen.

Bringing that back to Startups/Products: Let's say you have a startup and you
are going to build a Server Farm to support it. It used to be you had to order
the servers and Dell would take a month to ship them. You can't speed that up.
It is a fixed part of the timeline.

Let's say you want to build a new Electric car, the government testing for
crash and safety takes a fixed amount of time you can't speed that up.

The analogy is not just about can you speed something up by putting more
people on it, it is meant as a lesson that some processes are beyond your
control.

It is also used as a "build vs. buy" argument. "Apple just released a Feature
that we don't have" "Oh, no How long will it take us to build?" "9 months"
"That's too long we need this out by end of quarter". How do you do that? You
buy someone with that feature and you integrate for 45 days. Just like if your
rich uncle announces he has a week to live, and each Grand Nephew (I think
that is the kid of your Niece or Nephew) will inherit an equal split of his
Billion Dollars, so you need a baby tomorrow. You can't try to get your
girlfriend pregnant, that won't work in a week. Your only option is to buy or
steal a baby.

------
davmre
One difference between pregnancies and debugging is that the success
probabilities of pregnancies are more or less independent -- couple A's
failure to conceive doesn't cause us to believe that couple B will be any more
or less likely to succeed -- whereas bug-finding times are _not_ independent,
because all of your developers are searching for the same bug. If developer A
fails to find the bug in a week, then, assuming she is competent, the bug is
likely very subtle and so developer B will likely _also_ fail to find it.

This doesn't invalidate the argument entirely; adding developer B is clearly
no _worse_ than just using developer A (assuming B doesn't disrupt A's work
and also that we don't care about the cost of an extra developer), and, to
whatever degree B and A are using different strategies (giving them some
partial independence), it will somewhat reduce the tail probability that the
bug takes a long time to find. But the lack of independence, relative to the
pregnancy example, means that the gains probably won't be as dramatic as this
post assumes.

~~~
jonstewart
As an aside, there are many differences between pregnancy and debugging.

~~~
JoeAltmaier
Yeah, debugging and pregnancy are both difficult. But one involves long
sleepless hours, takes way too long with everybody looking over your shoulder
and giving advice, ruins your health and relationships. And the other one is
debugging.

------
erikb
Well, there are many things to disagree on. Many where already listed. These I
haven't found yet:

1\. I real baby doesn't always take 9 months. The same goes for software. Even
if you get over the first few hurdles it is still a guessing game how long it
takes. In fact Chinese people even say it takes 10 months for the baby to come
out.

2\. While the idea proposed by the author, that you can let teams work in
parallel to increase predictability of the results, might have many flaws, I
actually believe it pays out to think like that, because there are individuals
and teams who work way, way better than the average coder/team. If you let 3
teams tackle the same problem at the same time one of them might yield a much
better result than the others, and in that case will probably do it even
faster. And the next time you can just let the single best team work on a
problem and make a better profit margin.

------
kevinpet
> Unfortunately, I haven’t been able to find anywhere where he explains what
> he means by “the sequential nature of debugging”

It's clear to me that what Brooks is referring to is the sequential process
of:

1\. Let's try to use this functional. 2\. Whoops, a bug. 3\. Okay, I've fixed
the bug. 4\. Now the process blows up further along, or only in certain cases.
5\. Repeat until marketing insists on shipping.

------
eternauta3k
Chapter 26 of Ross Anderson's Security Engineering covers the probability
distribution involved in finding bugs, and its impact on software
vulnerabilities:

[http://www.cl.cam.ac.uk/~rja14/book.html](http://www.cl.cam.ac.uk/~rja14/book.html)

------
qwerta
My friend had baby in seven months (both are fine now)....

------
fndrplayer13
The author is taking this analogy far too literally. What else can you really
say?

~~~
muyuu
And he missed the fact that it's roughly 9.5 months even when everything goes
swimmingly (40 to 41 weeks). In some oriental countries like Japan, they talk
about 10 months pregnancies not 9 like in the West, where we count since the
first missing menstruation.

~~~
HCIdivision17
I think the whole thing works out well. You can't speed up the sequential bits
by throwing people at it, but you _can_ increase the chance of _finding_
elusive sequential bits (so long as people are already familiar - it can take
longer for strangers to have a baby than a married couple! [citation needed]).

And I think your comment balances it out nicely with: and it's already going
to take longer than quoted anyway!

------
diminoten
> is it actually the case that one woman can have a baby in nine months?

Yes, it is.

If your blog post's title is obviously false, you're doing yourself a
disservice.

------
Karunamon
tl;dr: Adding more people to a late project makes it later.

~~~
mason55
That's actually not what the post is about at all.

