Chapter 1: Key Points

1. 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 3x Programming System 3x Programming Product Programming Systems Product

2. 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

3. Perfectly Partitionable

4. Not Partitionable

5. Add Communication Costs

6. Complex Inter-relationships

7. 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

8. Chapter 4: Key Points • Few architects, many implementers • What problems can this cause?

9. 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?

10. 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?

11. 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

12. Chapter 8: Key Points • Try to get real data on projects comparable in size and complexity to yours for purposes of estimating.

13. 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?

14. 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?

15. 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”

16. 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?

17. 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?

18. 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

19. 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

20. 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

21. 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?

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