Mythical Man-Month

Team #2

n Gregory Paull

n Priscilla Wong

n Dave Fedorowich

n Dave Yan

n Olga Toporovsky

Introduction To Mythical Man-Month

n     Background Of the Book

u   First published in 1975

u   Anniversary edition in 1995

u   Author’s OS/360 experience

n     Why Programming is hard to manage?

n     Use of the book

u   Programmers

u   Managers

u   Managers of Programmers

Topics of Discussion

n     Chapter 1 – The Tar Pit

n     Chapter 2 – The Mythical Man-Month

n     Chapter 3 – The Surgical Team

The Tar Pit

   “Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it.”

                   - F. P. Brooks

Programming System
Product

n     Program to Programming Product

u   Cost at least triples

n     Program to Programming System

u   Costs at least triples

n     Program to Programming Systems Product

u  Costs goes up at least nine times

The Joys of the Craft

n     Joy of Making Things

n     Joy of Making Things That Are Useful To Other People

n     Puzzle-like objects

n     Joy of Always Learning

n     Pure Thought-Stuff

The Woes of the Craft

n     Requirement of Perfection

n     Goals are set by others

n     Dependence on other people’s programs

n     Debugging has a linear convergence

n     The product appears to be obsolete upon or before completion

Mythical Man-Month

n     Quote – “More software projects have gone awry for lack of calendar time than for all other causes combined.”

n     WHY?

u   Poor estimating Techniques

u   Confuse effort w/ progress

u   Bad estimation makes it hard for managers to do their job

u   Schedule progress is poorly monitored

u   Manpower is answer when delays occur

Problems

n     All Programmers are optimistic

n     Estimating and scheduling is done using the man-month, which is a myth

u  It implies that men and months are interchangeable

u  Only interchangeable when a task can be partitioned with no communication among programmers.

The  Man-Month

n     When a task can be partitioned but requires communication which may counteract the division of the task

u  training

u  intercommunication

Brooks’ Law

n     Brooks’ Law: “Adding manpower to a late software projects makes it later”

n     Adding people increases effort

u  repartitioning

u  training

u  communicating

n     The maximum number of men depends upon the number of independent subtasks

System Test

n     Underestimate time for testing

n     Rule of Thumb

u  1/3 Planning

u  1/6 Coding

u  1/4 Component test and early system test

u  1/4 System test, all components in hand

Surgical Team

n     The Problem

u  Wide productivity variations between good programmers and poor ones.

u  For efficiency and conceptual integrity, a small sharp team is best, but it is too slow for a really big system.

Mill’s Proposal

n     Mill’s Proposal - Surgical Team Approach

u  Offers a way to get the product integrity of few minds and the total productivity of many helpers, with less communication.

Surgical Team Communication pattern

n     In the surgical team, there are no differences of interest

n     Differences of judgement are settled by the surgeon

n     Article by Baker contains a small-scale test of this, which had great results

Analysis

n     How true is Brooks’ Law?

u  Abdel-Hamid And Madnic Research

u  Stutzke’s Research

u  None of the propositions asserted in the book have been proved or disproved

n     This book continues to be popular after 20 years.

Opinion

n     Great advise before going into a software project

n     Gives warning of problems that could arise before they arise

Questions & Answers