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

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 Partitionable

Not Partitionable

Add Communication Costs

Complex Inter-relationships

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!