This post originated from an RSS feed registered with .NET Buzz
by Chris Flaat.
Original Post: The Mythical Man-Month: So true it hurts
Feed Title: Chris Flaat's Weblog
Feed URL: /msdnerror.htm?aspxerrorpath=/cflaat/Rss.aspx
Feed Description: I mainly discuss tips & tricks about VS 2002, VS 2003, and upcoming versions of VS.
I have been devoting some time to matters of how to better manage a software
project, and have opened up a new category on my blog: "SD methodologies & processes".
Hopefully you will find it useful.
I have a terrible confession to make, my friends. There are still a few
people at Microsoft who haven't read "The Mythical Man-Month" by Frederick Brooks.
This book was written in 1975, yet somehow remains unbelievably relevant today.
The reason I think that not all at MS have read it is that when we've run out of time
in a coding milestone and someone wants to add yet one more feature, I will sometimes get
asked how many more people it would take to add it. Sometimes this is a reasonable
question (e.g. if it's a minor feature or if it's early in a product cycle), but more
often it's a bad question, and usually when we try to throw somebody at a feature
at the last minute it's not a pretty result.
One of the key points of this book is that if you are running out of time,
adding more people will actually slow you down. This is counterintuitive,
because in many kinds of labor (such as painting, grading potatoes, or busing tables)
you get more done with more people, even late in the project. But with software,
it's different. If you add more people, not only do you have to get a new developer
ramped up, other key people have to stop and help get them ramped up. Worse,
you now have to communicate things between more people and potentially get agreement
about technical details between more people, slowing the whole process down.
This is because software development is inherently communication-intensive work.
Brooks also discuss the inherent difficulty in writing systems software, which
is much more complex to design, write and maintain than end-user applications.
Much of this really hit home to what we do in Visual Studio, because we're often writing
components that others will consume in their programs, although we do write a lot
of code that is interacted with but not programmed against.
If you would presume to plan or manage a software project, I would highly recommend
this book. It comes in an "anniversary addition" with some additional essays.
Great stuff. -Chris
Previous Topic
