1. Mythical Man Month Fred Brooks, 1975

2. Why are software projects late? Estimating techniques are poorly developedEstimating techniques are poorly developed Our techniques confuse effort with progressOur techniques confuse effort with progress Since we are uncertain of our estimates, we don’t stick to themSince we are uncertain of our estimates, we don’t stick to them Progress is poorly monitoredProgress is poorly monitored When slippage is recognized, we add people (“like adding gasoline to a fire”)When slippage is recognized, we add people (“like adding gasoline to a fire”)

3. Optimism “All programmers are optimists”“All programmers are optimists” –“All will go well” with the project – thus we don’t plan for slippage –However, with the sequential nature of our tasks, the chance is small that all will go well

4. Optimism (cont) One reason for optimism is the nature of creativityOne reason for optimism is the nature of creativity –Idea, implementation, and interaction –The medium of creation constrains our ideas – in software the medium is infinitely malleable, thus we expect few problems in implementation, leading to our optimism

5. The Mythical Man-Month Cost does indeed vary as the product of the number of people and the number of monthsCost does indeed vary as the product of the number of people and the number of months Progress does not!Progress does not!

6. MMM (cont) The unit of man-month (person-month) implies that people and months are interchangeableThe unit of man-month (person-month) implies that people and months are interchangeable –This is only true when a task can be partitioned among many workers with no communication among them –When a task is sequential, more effort has no effect on the schedule – many tasks in software engineering have sequential constraints

7. MMM (cont) Most tasks require communication among workersMost tasks require communication among workers Communication consists ofCommunication consists of –Training –Sharing information (intercommunication) Training affects effort at worst linearlyTraining affects effort at worst linearly Intercommunication adds n(n-1)/2 to effort – if each worker must communicate with every other workerIntercommunication adds n(n-1)/2 to effort – if each worker must communicate with every other worker

8. Intercommunication effort 2 workers 1 path 3 workers 3 paths 46 510 615 721

9. Comparison graphs Adding more people then lengthens, not shortens, the schedule months No communicationWith communication people

10. Scheduling Brooks’ rule of thumbBrooks’ rule of thumb –1/3 planning –1/6 coding –¼ component test –¼ system test

11. Scheduling (cont) In looking at other projects, Brooks found that few planned for 50% testingIn looking at other projects, Brooks found that few planned for 50% testing But most actually spent 50% of their time testingBut most actually spent 50% of their time testing Many were on schedule until testing beganMany were on schedule until testing began

12. Development Team How should the development team be arranged?How should the development team be arranged? The problem: good programmers are much better than poor programmersThe problem: good programmers are much better than poor programmers –Typically 10 times better in productivity –Typically 5 times better in terms of program elegance

13. The dilemma of team size Consider a 200-person project with 25 experienced managers (experienced at programming, not necessarily at managing)Consider a 200-person project with 25 experienced managers (experienced at programming, not necessarily at managing) The previous slide argues for firing the 175 workers and use the 25 managers as the teamThe previous slide argues for firing the 175 workers and use the 25 managers as the team OS/360 had over 1000 people working on it, consumed 5000 person-years of design, construction and documentationOS/360 had over 1000 people working on it, consumed 5000 person-years of design, construction and documentation

14. Two needs to be reconciled For efficiency and conceptual integrity a small team is preferredFor efficiency and conceptual integrity a small team is preferred To tackle large systems considerable resources are neededTo tackle large systems considerable resources are needed One solution: Harlan Mill’s Surgical Team approach – one person performs the work (with a co-pilot), all others perform support tasksOne solution: Harlan Mill’s Surgical Team approach – one person performs the work (with a co-pilot), all others perform support tasks

15. Harlan Mills’ Surgical Team Surgeon – chief programmerSurgeon – chief programmer Co-pilot – like surgeon but less experiencedCo-pilot – like surgeon but less experienced Administrator – relieves surgeon of administrative tasksAdministrator – relieves surgeon of administrative tasks Editor – proof-reads documentationEditor – proof-reads documentation 2 Secretaries – support administrator and editor2 Secretaries – support administrator and editor Program clerk – tracks versionsProgram clerk – tracks versions Toolsmith – supports work of the SurgeonToolsmith – supports work of the Surgeon TesterTester Language lawyer (shared among multiple projects)Language lawyer (shared among multiple projects)

16. How is this different? Normally, work is divided equally – now only surgeon and copilot divide the workNormally, work is divided equally – now only surgeon and copilot divide the work Normally each person has equal say – now surgeon is absolute authorityNormally each person has equal say – now surgeon is absolute authority Note communication paths are reducedNote communication paths are reduced –Normally 10 people → 45 paths –Surgical Team → at most 13 paths [?]

17. How does this scale? Reconsider the 200 person team – communication paths →19,900!Reconsider the 200 person team – communication paths →19,900! Create 20 ten-person surgical teamsCreate 20 ten-person surgical teams Now only 20 surgeons must work together – 20 people → 190 pathsNow only 20 surgeons must work together – 20 people → 190 paths The key problem is ensuring conceptual integrity of the designThe key problem is ensuring conceptual integrity of the design

18. Conceptual Integrity (cont) With respect to software, design by too many people results in conceptual disunity of a system, making the program hard to understand and useWith respect to software, design by too many people results in conceptual disunity of a system, making the program hard to understand and use Better to leave functionality out of a system if it causes the conceptual integrity of the design to breakBetter to leave functionality out of a system if it causes the conceptual integrity of the design to break

19. Function vs. Complexity An important metric for evaluating a system’s design is its ratio of functionality to conceptual complexityAn important metric for evaluating a system’s design is its ratio of functionality to conceptual complexity Ease of use is enhanced only if the functionality provides more power than it takes to learn (and remember) how to use it in the first placeEase of use is enhanced only if the functionality provides more power than it takes to learn (and remember) how to use it in the first place

20. Architects as Aristocrats Conceptual integrity requires that the design be the product of one mindConceptual integrity requires that the design be the product of one mind The architect (or surgeon) has ultimate authority (and ultimate responsibility)The architect (or surgeon) has ultimate authority (and ultimate responsibility) Does this imply too much power for architects?Does this imply too much power for architects? –Architect sets the structure of the system –Developers can then be creative in how system is implemented

21. Communicating design decisions Written specifications - “The Manual”Written specifications - “The Manual” –Answers questions –Conceptual integrity –Demands high precision Telephone log – make sure to capture all design decisionsTelephone log – make sure to capture all design decisions Product test – external test group keeps implementation honestProduct test – external test group keeps implementation honest

22. Formal Definitions Natural language is not preciseNatural language is not precise Notations help express precise semantics – however, natural language is often needed to “explain” the meaning to the uninitiatedNotations help express precise semantics – however, natural language is often needed to “explain” the meaning to the uninitiated

23. Formal Definitions (cont) What about using an implementation?What about using an implementation? –Advantages: precise specification –Disadvantages: Over-prescription, potential for inelegance, may be modified –Inconsistencies between multiple implementations can identify problems in the specs – with only one implementation its easier to change the manual

24. Reducing communication paths Communication needs are reduced byCommunication needs are reduced by –Division of labor –Specialization of function

25. Management question Plan to build a system to throwawayPlan to build a system to throwaway –Experience gained, feedback can be applied Plan to build a throwaway that is delivered to the customerPlan to build a throwaway that is delivered to the customer –User is aggravated and demands support

26. Rapid prototypes Help gain early feedbackHelp gain early feedback Intended from start to be thrown awayIntended from start to be thrown away Brooks instead focuses on planning for change in a large software projectBrooks instead focuses on planning for change in a large software project

27. Causes of change Both the actual need and the user’s perception of that need will change as programs are built, tested and usedBoth the actual need and the user’s perception of that need will change as programs are built, tested and used Other factors – hardware, assumptions, environmentOther factors – hardware, assumptions, environment

28. Maintenance Two steps forward and one step backTwo steps forward and one step back –Life cycle of bugs –Fixing a bug has a chance of adding another – lots of regression testing needed One step forward and one step backOne step forward and one step back –Maintenance is an entropy-increasing process –As maintenance proceeds, system is less structured than before, conceptual integrity degrades

29. The whole and the parts Top-down designTop-down design –Design as a set of refinement steps –Use of abstraction at each level –Modular decomposition Other techniquesOther techniques –Structured programming –Object-oriented design –Reuse