The Mythical Man-MonthDue Today: Code & Coding StandardsDue Next Class: Quiz #3; see webpage

• Mythical Man-Month I• Bio Break• Mythical Man-Month II• Questions / Review for Quiz #3

Chapter 1: Key Points• Program = Useful to the programmer in the garage• Programming Product = Useful to anyone• Programming System Component = Part of a collection of programs

that work together doing a bigger job• Programming Systems Product = The collection of components; what

you are after, 9X as expensive as creating a “program”

Program

Programming Systems Product

Programming Product

Programming System

3x

3x

Chapter 2: Key Points

• “All programmers are optimists”• “Men and months are interchangeable commodities only when a task can be

partitioned among many workers with no communication between them.” • “The bearing of a child takes nine months, no matter how many women are

assigned.”• Costs: training. Intercommunication.• “Take no small slips” (in schedule)• Brooks Law: “Adding manpower to a late software project makes it later.”

– Abdel-Hamid & Madnick 1991: “Adding more people to a late project always makes it more costly, but does not always cause it to be completed later.” Perhaps: Brook’s “rule of thumb.”

• Bottom line: Non-linear trade-off between persons and person-months

Perfectly PartitionablePerfectly Partitionable Task

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

people

mon

ths

Not PartitionableUnpartitionable Task

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

people

mon

ths

Add Communication CostsPartitionable w/ communication

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

people

Mon

ths

Complex Inter-relationshipsComplex Inter-relationships

0

50

100

150

200

250

300

350

400

1 2 3 4 5 6 7 8 9

people

mon

ths

Chapter 3: Key Points

• Sackman, Erikson & Grant Study ratio between best and worst productivity performance of programmers: 10:1

• Surgical team approach vs. hog butchering• Team Members:

– Chief Programmer– Co-pilot– Administrator– Editor– Secretaries– Program Clerk– Toolsmith– Tester– Language lawyer

Chapter 4: Key Points

• Few architects, many implementers• What problems can this cause?

Chapter 5: Key Points

• Role of architect vs. implementer• What issues can arise?• The second system effect (similar to goldplating)• How to avoid the second system effect?

Chapter 6: Key Points

• How to communicate with teams of hundreds?

• Weekly ½ day conference of architects + key implementers– Same group each week– Smart people, all hands-on– Problem-solving focus– Written proposals for decisions– Clear decision-making authority

• Log of all questions & answers (website)• Early test involvement

• Problems with this?– What about information hiding?

Chapter 7: Key Points

• Lesson of the tower of Babel• Communication means:

– Informal– Meetings– Workbook / Notebook– Website today… how would you do it?

• Elements of success:– Mission– Producer– Technical director/ architect– Schedule– Division of labor– Interface definitions among the parts

Chapter 8: Key Points

• Try to get real data on projects comparable in size and complexity to yours for purposes of estimating.

Chapter 9: Key Points

• Understand your constraints. In the early days this was memory space… memory rented for $12/K/month

• Representational v. computational equivalence (Herb Simon)• What are the constraints today?

Chapter 10: Key Points

• Documentation for a “computer product”– Objectives– Specifications– Schedule– Budget– Organization chart– Space allocations– Market forecasts

• Do you agree or disagree with this list? What would you add? Take away?

Chapter 11: Key Points

• “Plan to throw one away; you will, anyhow.”– Do you agree? What about incremental model?

• On requirement changes: “a threshold has to be established, and it must get higher and higher as development proceeds.”

• What prevents a design from getting documented?

• The semi-U shaped bug curve (Campbell’s data)

• The fixing the fixes problem, or “program maintenance is an entropy-increasing process”

Chapter 12: Key Points

• Vehicle (aka development) machines and target machines• How would you plan machine usage?• Importance of high-level languages… examples today?• What other tools are important?

Chapter 13: Key Points

• Prevent bugs in design• Test the specification … how?• Stepwise refinement• Use debugged components … why?• Change control• Add one component at a time… why?

Chapter 14: Key Points

• “How does a project get to be a year late? …. One day at a time.”• What makes a good milestone?

– Concrete, specific, measurable, “defined with knife-edged sharpness”• Studies show:

– Estimates before work begins do not change– During work, over-estimates steadily come down– During work, under-estimates do not change until 3 weeks before

completion.• How do you tell which slips matter most? (Pert charts, critical path)• What Bosses need:

– Exceptions to plan that require action– Status pictures for education– Helps to label meetings, “status” or “action” meetings

Chapter 15: Key Points

• Documentation for the user – what would you change/add on this list?– Purpose– Environment– Domain & Range– Functions– I/O formats– Operating instructions– Options– Running time– Accuracy and checking

• Documentation for the maintainer• Self-documenting code

Chapter 16: Key Points

• “No silver bullet.” Advice:– Buy rather than build– Use rapid prototyping to help establish requirements– Grow software organically (aka incremental development)– Find the good conceptual designers

• Some tough issues:– Complexity– Conformity– Changeability– Invisibility

Chapter 17: Key Points

• OO might be the “brass bullet.”– But lots of up-front costs– Re-use more common at large companies than small … why?

Chapter 18

• This is Fred’s summary of the book. You should read this one chapter if nothing else!

Quiz #3 ReviewTopics

• ALL of the Material on Quiz #1• ALL of the Material on Quiz #2• Why Configuration Mgmt is needed• Key Configuration Mgmt concepts• Key OO concepts• Advantages / disadvantages of OO• Cleanroom v. Waterfall process• Key cleanroom concepts• Advantages / disadvantages of cleanroom• How to do a Demo• Testing Principles• White Box v Black Box testing• Elements of a Test Plan• Regression testing: what? why? how?• Stress testing: what? why? how?• SQA techniques … review homework topics!• Mythical-Man Month… for sure!• Extra credit?

• Covers all the lectures and all the reading to date.

• Approximate weighting:

• 50% old stuff

• 50% new since quiz #2

• Format:

• Multiple Choice

• Short Answer

• Essay• If your average on the 1st 3 quizzes is greater than 80%, the final is optional. The final is equivalent to a 4th quiz in weight.