One woman can’t have a baby in nine months (2007)(gigamonkeys.wordpress.com)
gigamonkeys.wordpress.com
One woman can’t have a baby in nine months (2007)
http://gigamonkeys.wordpress.com/2007/05/10/baby-in-nine-months/
18 comments
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.
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.
> 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.
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.
> 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!"
So budget a generous amount of time for the driver up front.
So budget a generous amount of time for the driver up front.
The problem is when you are one one cog in a much larger machine. My team has a specific launch date for a major release of our piece of the product. The ten other teams around us depend on our release, and are going to meet their deadlines. The loss of one piece is the loss of the whole project.
Ideally, one should never let this situation happen- but it will.
Do I force the whole company to slip? Or do I accept that my piece is going to be crap at launch, but follow up and make it better later? Both options exist, and should be on the table. Which you pick is really up to the situation.
Ideally, one should never let this situation happen- but it will.
Do I force the whole company to slip? Or do I accept that my piece is going to be crap at launch, but follow up and make it better later? Both options exist, and should be on the table. Which you pick is really up to the situation.
When I was at Microsoft there was a phenomenon known as "schedule chicken" whereby each team in an interdependent group would report up "no problem totally on schedule" despite being way off in the hopes that some other (perhaps even more off-target) group would admit they needed to slip the date. Then all the other groups could breathe a sigh of relief and say, "We totally could have made it but given that those guys slipped the schedule, we'll use the time just to be extra awesome." Of course the problem is that if everyone plays this game, you end up right before the deadline with lots of groups simultaneously admitting they're nowhere near ready and you have a huge mess on your hands.
Exactly. But we're actually talking about 3 things: time, quality, and scope. Pick any two.
I had the pleasure of working with a company that preferred time and quality, and were willing to negotiate scope. It worked really well, because, from the outside, it looked like we were releasing on a regular basis (so it looked alive), at high quality, and on the inside, we knew we'd ship the more difficult parts of the project eventually, but without the stress that goes with trading off time or quality.
I had the pleasure of working with a company that preferred time and quality, and were willing to negotiate scope. It worked really well, because, from the outside, it looked like we were releasing on a regular basis (so it looked alive), at high quality, and on the inside, we knew we'd ship the more difficult parts of the project eventually, but without the stress that goes with trading off time or quality.
Regarding ship times, it seems to depend on the industry as well as commercial vs enterprise software as well. New products and old products make a difference as well. On new products, I think you are generally correct but on established products companies can get by doing this.
The first company I worked for professionally was enterprise software and the market leader in the space had a tendency for years to knowledgeably ship poor quality products at specific times either due to legal reasons or financial reasons. They would try to staff up for releases and use contractors and all sorts of techniques to actually make the releases semi-legitimately. There was an unspoken acknowledgement not to use those versions though (actually I think they actually put a sleeve in the DVD saying not to install it in production once and to wait for the next point release coming in 2 months). I left them and became their customer and currently use 7 year old versions because the latest versions break things we need but its known that you never install their shipping version and wait for at least the first service pack.
I know in one case some customer contract/government mandate specified releases must be made by end of calender year so regardless there was a release regardless of current state of the project. The other cases were usually financial and it was due to something like if the DVDs physically shipped by end of quarter then revenue could be recognized in that quarter. Since this is enterprise the customer may or may not pay at that time since they are usually just paying yearly support but its the accounting games that are played that forced the time. In my current company we use standard accounting practices and our VCs have told us that if we are not using "creative" accounting we are doing it wrong so revenue recognition times or invoice time sneak in rather than collection time into the books.
The first company I worked for professionally was enterprise software and the market leader in the space had a tendency for years to knowledgeably ship poor quality products at specific times either due to legal reasons or financial reasons. They would try to staff up for releases and use contractors and all sorts of techniques to actually make the releases semi-legitimately. There was an unspoken acknowledgement not to use those versions though (actually I think they actually put a sleeve in the DVD saying not to install it in production once and to wait for the next point release coming in 2 months). I left them and became their customer and currently use 7 year old versions because the latest versions break things we need but its known that you never install their shipping version and wait for at least the first service pack.
I know in one case some customer contract/government mandate specified releases must be made by end of calender year so regardless there was a release regardless of current state of the project. The other cases were usually financial and it was due to something like if the DVDs physically shipped by end of quarter then revenue could be recognized in that quarter. Since this is enterprise the customer may or may not pay at that time since they are usually just paying yearly support but its the accounting games that are played that forced the time. In my current company we use standard accounting practices and our VCs have told us that if we are not using "creative" accounting we are doing it wrong so revenue recognition times or invoice time sneak in rather than collection time into the books.
Interestingly, the Macintosh project slipped many times, despite being the source of the "Real Artists Ship" mantra, which is often taken to mean, "it's always better to ship than to slip."
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.
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.
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
This is why you have collaboration software such as Atlassian's Confluence, Jira, etc. The questions get posted to the collaboration site, linked with the code under review, and developers can find answers to questions that have already been asked.
Even better, as the questions get answered you can have more tests in the codebase so the developers can find the answers before they ask the questions.
You do raise the interesting issue conveniently left out of the original article though: if you put 100 couples onto "Project Baby", you have a very high chance of getting multiple babies even when you only wanted one.
Even better, as the questions get answered you can have more tests in the codebase so the developers can find the answers before they ask the questions.
You do raise the interesting issue conveniently left out of the original article though: if you put 100 couples onto "Project Baby", you have a very high chance of getting multiple babies even when you only wanted one.
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.
* 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.
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.
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.
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.
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.
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.
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.
Carry a baby, not conceive a baby. OP (deliberately) misinterpreted the meme for comic effect.
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.
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.
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
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
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.
I think the main message that independently working on the same task can be a weak parallelization of random time tasks (independently random depending who is working on it). It simply falls in the category of "less than linear speed-up" parallelization. Since it is a trivial one, you can take it into account most of the time, however it's not too efficient.
Can we say courting is the equivalent of the 'train-up' period for having a baby?
Definitely THAT can be parallelized. Just play the field!
But make sure that you have proper isolation between the subtasks.
Still you can't parallelize design/coding/debugging/packaging, much. Maybe each of those tasks can be individually, weakly.
He also ignores overhead. Say you assign 5 teams to fix a bug and 2 finish it that day. Which code get's committed? First sounds great but the odds of solving the wrong problem or introducing another bug are high. As first team may have just missed the real issue. So now you compare solutions which adds another step.
Now what happens if the bug is less than clear? You now have 5 teams that want to ask more or less the same questions.
Now what happens if the bug is less than clear? You now have 5 teams that want to ask more or less the same questions.
Not the majority of the time; the long pole on the project. It won't be done-done until the long pole is done. So the schedule can't be brought in by adding 'resources'.
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 ;)
Exactly. If your software is only going to be used more than once, then any notion of "finished" is illusory and often toxic.
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 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.
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 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.
> 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".
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".
> 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.
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.
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.
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.
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.
> is that the success probabilities of pregnancies are more or less independent
Or rather, if they demonstrate dependence, there's probably a factor outside of the pregnancy that's causing the problem (environmental stressors, toxins, etc.)
Or rather, if they demonstrate dependence, there's probably a factor outside of the pregnancy that's causing the problem (environmental stressors, toxins, etc.)
As an aside, there are many differences between pregnancy and debugging.
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.
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.
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.
> 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.
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.
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
My friend had baby in seven months (both are fine now)....
The author is taking this analogy far too literally. What else can you really say?
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.
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!
And I think your comment balances it out nicely with: and it's already going to take longer than quoted anyway!
The blog post isn't about that at all. Did you read it to the end, or did you ctrl+tab to write a middlebrow dismissal on HN after the 5th paragraph?
> 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.
Yes, it is.
If your blog post's title is obviously false, you're doing yourself a disservice.
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.