Mythical Man Month

1. Mythical Man Month Fred Brooks, 1975

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

3. Optimism • “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 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 months • Progress does not!

6. MMM (cont) • The 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 workers • Communication consists of • Training • Sharing information (intercommunication) • Training affects effort at worst linearly • Intercommunication adds n(n-1)/2 to effort – if each worker must communicate with every other worker

8. Intercommunication effort

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

10. Scheduling • Brooks’ 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% testing • But most actually spent 50% of their time testing • Many were on schedule until testing began

12. Development Team • How should the development team be arranged? • The 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) • The 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 documentation

14. Two needs to be reconciled • For efficiency and conceptual integrity a small team is preferred • To 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 tasks

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

16. How is this different? • Normally, work is divided equally – now only surgeon and copilot divide the work • Normally each person has equal say – now surgeon is absolute authority • Note 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! • Create 20 ten-person surgical teams • Now only 20 surgeons must work together – 20 people → 190 paths • The 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 use • Better 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 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 place

20. Architects as Aristocrats • Conceptual integrity requires that the design be the product of one mind • The architect (or surgeon) has ultimate authority (and ultimate responsibility) • 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” • Answers questions • Conceptual integrity • Demands high precision • Telephone log – make sure to capture all design decisions • Product test – external test group keeps implementation honest

22. Formal Definitions • Natural language is not precise • Notations 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? • 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 by • Division of labor • Specialization of function

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

26. Rapid prototypes • Help gain early feedback • Intended from start to be thrown away • Brooks 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 used • Other factors – hardware, assumptions, environment

28. Maintenance • Two 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 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 design • Design as a set of refinement steps • Use of abstraction at each level • Modular decomposition • Other techniques • Structured programming • Object-oriented design • Reuse