The Mythical Man Month after 20 Years

1. The Mythical Man Monthafter 20 Years Trevor Spicer Group 4

2. The MMM in Perspective • Originally Written in 1975 • Virtually ALL software was custom • Dozens of operating systems • No public network • 20th Anniversary in 1995 • Most software was shrink-wrapped • Handful of Oss • Internet in public infancy

3. Why a 20th Anniversary Ed.? • Book still relevant & useful • While technology has exploded, software development discipline still vital • MMM is primarily about people and teams • Specifically how we make things • So what has stayed the same and what has changed?

4. Conceptual Integrity • One architect • Verdict: as relevant as ever • Commercial software (of any significant size) typically cannot be built by one person. • Market pressure • Complexity • Must be conceptually coherent to the single mind but at the same time be designed by many

5. How do we do that for large projects? • Recursion of architects • System Master • Partition subsystems w/ clear boundaries • Each w/ own architect • Author more convinced than ever: • “Having a system architect is the most important single step toward conceptual integrity”

6. On the issue of the Second System Effect • Designing systems for larger user set. • Vast majority of software is built for the masses • Pre-packaged • 100K’s to Millions of copies • Custom applications far less frequent • Defining the “user” • Large, less defined user set • Each team member (inc. the Architect) will have their own idea of “a user” • Design team must arrive at a single shared image • Featuritis • Word 6.0 packs in features • Word 6.0 is also big and slow

7. …. On the issue of the SecondSystem Effect • Brook’s “gotcha” • The “second system” [effect] comes after throwing away the first • Developers “2nd system” is the most dangerous • Linguistic contradiction • So is there still a second system effect? • Or SHOULD there still be the effect? • Hold this thought!

8. Triumph of the WIMPs • In many ways software has itself changed • Windows, Icons, Menus, Pointing • Conceptual Integrity via metaphor • A user’s desktop • Danger of users becoming too tied to the metaphor • Put a disk “in the trash” to eject it? • Fails: Menus & one-handedness • Power Users vs. Ease of use • Keyboard shortcuts (basic to arcane)

9. Side thoughts on WIMP • Novice users with: • Keystrokes • Command-line • Abstraction between data and display • Reinforcing & Breaking the metaphor • Multitouch (ala. MS Surface) • Mobile Phones • Widgets (Sidebar, Dashboard, etc) • MIT Fluid Interfaces Group “Sixth Sense” research • (1995) Brooks on WIMP: Voice Navigation • New Apple Shuffle

10. Waterfall Model: Don’t build one to throw it away • The Waterfall Model is wrong • Too simplistic • Sequential model of software construction • Implies that repairs can be made easily down the road – ie that the realization of the project is correct • Puts end user testing at the end • Assumes that the whole system is built at once

11. Waterfall Model… cont • Changes that are needed • Early testing for end users • Upstream movement: the experience from downstream must often leap back upstream to affect the development process • So, what are some different models?

12. Other Models • These are not mutually exclusive! • End-to-end skeleton system • Think of this like a core process w/ subroutines, tested each time one is introduced • At every stage we have a running system • Family of related products • Design tree w/ least likely to change decisions at the root • Incremental build strategy

13. Other Models, cont • Build Every Night • Microsoft, Open Source, etc • Also, Build and Release Often • Aplha, Beta’s • Incremental Build and Rapid Prototyping • Early user feedback • Limited in function

14. Information Hiding • Originally all developers knew (or had access to) everything else • Now, modules of code should be encapsulated from the rest • Each has its own well defined spec • Developer “owns” the inside and is shielded from everything else • Conceptual chunks • This method is robust under change

15. People are Everything • Quality of people (talent, organization, management) are more important than technical approaches • Sharp tools are great but won’t make up for care, growing and feeding of people. • Moving projects = FAIL • Team fusion • New teams tend to simply start over • Creativity of smallness – large firms and small teams

16. 1975 – 1995 Surprises • Millions of Computers • Computers = fluidity • Example of manuscript typed vs. word processed • Programming • Other content as well • Pace of development • Time is almost obsolete (think compiling, global collaboration, etc)

17. Surprises Cont… • Whole new software industry • Classic vs. Shrink-wrapped • Operating systems have coalesced • Even more now! • Metaprogramming • High-level (Hypercard, Excel, Macros, etc) • Attack the “essence” because of a lack of discipline

18. State and Future of Programming • Tar pit will continue to be sticky • “This complex craft will demand our continual development of the discipline, our learning to compose in larger units, our best use of new tools, our best adaptation of proven engineering methods, liberal application of common sense, and a God-given humility to recognize our fallibility and limitations.”

19. Trevor’s thoughts • 14 years and a great deal has changed. • Not necessarily with all of the tools. VB 5 (1997) vs now • But with some… Internet, time shifting • But with the culture. • Mobile Phones, ubiquitous computing • Smaller apps • Trending away from super-large, proprietary systems (think UNIX) • Standardization: Internet apps: Web Services, protocols • System independent programming – killing metaphors: Web, also virtualization, cross-platform • We must view book from within the context of an engineering course (larger systems)