The Mythical Man-Month Book Cover
So I stopped by Borders last night with Katie and did what any good nerd would do, immediately high tail it to the computer reference section to check out the latest releases.
Initially I peered around for new production books or project management techniques, but my eyes got caught on one particular piece. I had read about The Mythical Man Month before in Rapid Development; where it received high praise for its groundbreaking observations (groundbreaking for 1986 anyways) in the software development industry.
The book is essentially a collection of essays written by Frederick P. Brooks Jr, in an effort to persuade developers into avoiding the same tar pits that sunk many development projects and studios. I'm pleased to say that Brooks work did not go unnoticed, as even the most basic programmer is being made aware of the ideas brought forth in The Mythical Man Month through Computer Science classes the world over.
Herein lies a summary of the chapters core ideas, for future reference
Ch.1- The Tar Pit
Small garage programming teams are great at programming systems, while professional development teams are best for developing products.
Ch.2- The Mythical Man-Month
Using the classic man-month system for estimating software development times is dangerous, because it assumes that the amount of manpower and months till completion are interchangeable.
Ch.3- The Surgical Team
Best and worst performances among programmers average at a ratio of 10:1, also a small ten man team that is highly trained to work as a single unit (referred to as a surgical team) can be scaled up in size to include multiple surgical teams using proper technique in order to lower the time to market, allowing the product to be feasible in the marketplace.
Ch.4- Aristocracy, Democracy, and System Design
Balance your product for ease of use and functionality. Also there needs to be checks and balances in your products feature creation, a democratic system of deciding feature sets that includes the whole team instead of an elite few leads to chaos and disorder. The object of development is for many cogs working together to bring about one vision. Lastly implementers (cogs) still have plenty of room for their creative expression and inventiveness to shine through in their daily work. Avoid the sirens song of having the many do the task that would be best given to the few because of the fear of implementers not showing off their creativity.
That's as far as I've gotten for now, I'll be posting more chapter summaries in the next few weeks as I read through them.
No comments:
Post a Comment