Engineering Management Hacks: The BigBook Technique
I'm just going to keep repeating this story until it becomes common knowledge. Apparently the need still exists! (Aperture is far from the only recent example.)
In 1996, a company called BigBook tried to make what we now know as Google Maps/Yahoo Local -- an online, map-based business directory. (BigBook was across the street from, and supported by, Organic, where I worked at the time. The engineering teams comingled quite a bit, and I believe I heard this story from two of their coders; though if anyone with direct knowledge wants to confirm or deny the story in the comments, go for it.) They did a great job in a really short period of time, apparently turned down an acquisition offer from Yahoo in order to go for bigger bucks, stumbled along the way, and eventually sold to one of the legacy Yellow Pages companies.
Many of the engineers were smart folks from Sun. During the run-up to their launch, the schedule slipped significantly, and the CEO (overall a great guy) made the classic engineering management mistake of adding many more developers to the late project in hopes of speeding its completion. The engineers, of course, knew the definitive text about this mistake: Frederick Brooks' The Mythical Man-Month, which argues:
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging. In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. [...] Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later.
After failing to win several arguments on this point, the engineers became exasperated and decided to hold an intervention with the CEO. They each bought a copy of Brooks' book, brought the CEO into a conference room, and stacked up the copies of the book, telling him, It is extremely urgent that you read this book. We've bought you many copies so that you might read it faster. They made their point.
If you find yourself on a software project where management keeps piling on people to make it go faster, make the argument first. If it fails, employ the BigBook Technique and hammer home the point. (Disclaimer: no, O'Reilly didn't publish Brooks' book...) There's no excuse for a company producing any kind of software to make this mistake: Brooks' book was published in 1975.
tags: hacks
| comments: 16
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4643
Comments: 16
I was an engineer and engineering manager at Xerox for many years turning out digital products. We could never get senior managment to read Brooks' book. Another thing we could never get them to do was to read the studies that show that at after about 50 hours/week the next hours actually COST money due to the increased rate of errors that have to be fixed.
Good to remember this book, I think there is a CEO who should read it very urgently ... in my company !
Steve McConnell pointed out in a great interview with itconversations.com, that the Os/360 project, based on which Brooks wrote the book was rather unique in some respects - The OS/360 team was 5000 strong. Very few development efforts ever have teams that size and concerns about adding more staff and increase the number of communication paths are rooted in the problems faced by a 5000 member team. Mailing lists, wikis and other colloboration tools were not as intensely used during Brook's time - I wonder how such tools undermine Fred Brooks' contentions about adding more staff. If you are looking for a critical take on some of the things Fred Brooks said, that itconversations interview with Steve McConnell is a good starting point.
It doesn't matter how big the team is. Even if you aonly have two people working on the project, it will still take a lot of time to get a third person up to speed.
Every time we hire a new person, I expect that our productivity will go down by about one to two people. It takes a month or two just for the new person to break even, and as many as three before the time they suck from everone else is less than the time we save by having the new hire.
Hi, I worked as an engineer at BigBook before and after the launch and while I take issue with some of the details, the ultimate jist of this post is accurate. After leaving bigbook in 1997, I have referenced The Mythical Man Month too many times for me to count. And yet, this sort of error is still made today, including a project I've been working on for the last five years...
C'est la vie.
Huh? Wikis were not as intensely used in 1975, because they were invented in 1995.
I don't know about mailing lists... but I bet they would be shocked at the flagrant waste of a computer just to deliver mail, when there was a very efficient person with a push-cart who did that.
Great story, Marc. Using the wonderful technique of bringing in multiple copies of the same book to read to drive home the point does suggest the opposite: you can sometimes save time with fewer people, or less of a book. We're increasingly thinking at O'Reilly about "less is more" publishing, including the SafariU remix engine, as well as formats like hacks, Developer Notebooks and Cookbooks.
This original post, and all the comments, describe in an interesting manner the changes of the past 30 years in computers, software, and information about computers and software.
1. Often individuals or small teams have ideas that later become famously profitable for someone else. I remember that dial-up system I set up in my cellar in 1991, where the concept was going to be that out-of-work software developers could use their modems to dial into a system and find text listings of available positions in various cities. A kind of computerized classified ads that matched employers with potential employees. It seemed like a great idea for out-of-work people (1991 was a software recession) who knew how to dial into a bulletin board site using a modem!
2. Software development today is still not something you can throw "bodies" (I hate it when employers use that term) at.
3. A change, though: today a small team can be incredibly successful more easily than in the past, in my opinion (37 Signals)... Because there is an enormous amount of working software available as a base.
4. Documentation has perhaps changed even more, though. The Internet makes possible searching for obscure error messages and finding many texts about that message. But, the filtering process is incredibly time consuming. Printed books have a role, but, if O'Reilly is on target, that role is changing. O'Reilly sales suggest they are on target.
5. Technology today makes it possible for tiny teams to produce products that once required large teams. My 1991 version of Monster.com never got very far, but next week our 2-person publishing company (my wife and me) publishes our first book, a guide for parents and teens on how to use MySpace.com safely. Our maximum financial loss: $400. But will anyone buy our book? Or will everyone just search Google and get all the information online? What profit is actually possible for 1000 hours of our time?
6. Innovation is very difficult when you are "too small." Today, the definition of "too small" has gotten smaller, but I think "too small to be likely to succeed" still exists.
7. A possible caveat, thought, is the "revolution" that blogging and social networking are creating, because it's almost as though the individual or tiny team isn't totally isolated, as was the case even 10 years ago. Blogging and social networking are part of a new revolution in media, says the Economist in their April 22 "survey of new media". I subscribe to blogs, and apparently people are interested in things I consider interesting enough to write about on my own blogs. I mean, O'Reilly Radar is a blog, really, right? As a result, our tiny publishing company "converses" with O'Reilly in a way that was not possible 10 years ago. Different levels of collaboration can exist, that were not possible in the past...
BigBook today might have had a community of interested followers that was not possible in 1996. Today, it might have become like 37 Signals. Maybe...
I was under the impression that Wehrner von Braun
came up with the saying that crash programs don't succeed for the same reason that getting 9 women pregnant won't get you a baby in a month's time
Seems kinda important to remember the sources, otherwise soon everything will be attributed to Einstein or Oscar Wilde
Somebody's right (ironically, anonymously): Braun was the source of the 9 women quote. Also, ironically, I swear I've heard the claim that all quotes will end up the province of Wilde or Einstein.
Neil K correctly pointed out that Wikis were only invented in 1995 and thus couldn't have been used on the OS/360 project. He adds: "I don't know about mailing lists". The state of the art system that these guys were developing was a batch system based on punched cards, so e-mail wouldn't have existed then either (we're talking the mid-1960s).
But going back to the original point, e-mail doesn't necessarily speed up interaction between programmers. Exchanging endless e-mail threads instead of having face to face meetings could, in fact, slow projects down.
Also, Jonathan Allen pointed out that new hires need to be trained, and this lowers productivity in the short term. Another problem of adding a significant number of new hires is that you need to add new layers of management. If a single programming manager has 20 direct reports, he won't be able to keep his head above water very long.
I heard it WAS Einstein that said: ...'these days it seems it's either me or Oscar Wilde that gets blamed for all those pithy quotes...'
A major exhibition of work by French-American sculptor Louise Bourgeois is to be held at Tate Modern...
A major exhibition of work by French-American sculptor Louise Bourgeois is to be held at Tate Modern...
Technology today makes it possible for tiny teams to produce products that once required large teams. Small is the new BIG!
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- David Wilhelm on Engineering Management Hacks: The BigBook Technique: Technology today makes ...
- Rylee Cason on Engineering Management Hacks: The BigBook Technique: A major exhibition of w...
- Rylee Cason on Engineering Management Hacks: The BigBook Technique: A major exhibition of w...
- wild on Engineering Management Hacks: The BigBook Technique: I heard it WAS Einstein...
- yoda on Engineering Management Hacks: The BigBook Technique: Neil K correctly pointe...
- Rob Williams on Engineering Management Hacks: The BigBook Technique: Somebody's right (ironi...
- somebody on Engineering Management Hacks: The BigBook Technique: I was under the impress...
- Kevin Farnham on Engineering Management Hacks: The BigBook Technique: This original post, an...
- Tim O'Reilly on Engineering Management Hacks: The BigBook Technique: Great story, Marc. Usi...
- Neil K on Engineering Management Hacks: The BigBook Technique: Huh? Wikis were not as ...
RADAR TOPICS
Matt Turner [05.12.06 02:41 AM]
I loved that book, it was also really interesting from the view of historic computing (everyone being given printed copies of the code, having to wait in turn to use a computer!!!)
I was only on a project last year that was slipping, lots of people worked REALLY late (and spent the next morning undoing mistakes they made the night before) and they assigned extra people. Well, it did help to some extent but by that point the damage had already been done. There was no one technical enough heading the project to give the site a strong architecture, it's like the leaning tower of piza with sticky plasters!
Anyway, read the book if you haven't already, it's not too long and very worth while.