Greetings dear readers -

  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