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

mo

nth

s

Not PartitionableUnpartitionable Task

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

people

mo

nth

s

Add Communication CostsPartitionable w/ communication

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

people

Mo

nth

s

Complex Inter-relationshipsComplex Inter-relationships

0

50

100

150

200

250

300

350

400

1 2 3 4 5 6 7 8 9

people

mo

nth

s

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!