Slide TMMM.1/28 The Mythical Man-Months

Slide TMMM.2/28 Overview Fred Brooks and OS/360 The Mythical Man-Month What has and has not changed? No Silver Bullet Analysis

Slide TMMM.3/28 Frederick P. Brooks Jr.

Slide TMMM.4/28 Frederick P. Brooks Jr. Undergraduate degree in physics from Duke University in Master's and Doctorate degrees in computer science from Harvard University Left IBM in 1965 to found the Department of Computer Science at UNC-Chapel Hill Won the 1999 A.M. Turing Award, considered the “Nobel Prize of Computing”

Slide TMMM.5/28 OS/ man-years of effort at IBM Introduced in 1963 but not completed until 1968 Fred Brooks was IBM’s project manager between 1964 and 1965 Still used today in a new form as OS/390, the old source is almost completely gone

Slide TMMM.6/28 The Man-Month Myth “Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.” -Fred Brooks

Slide TMMM.7/28 Men to Months Relation

Slide TMMM.8/28 Brooks’s Law Adding manpower to a late software project makes it later. –We can always create schedules with fewer men and more months –We cannot always create schedules with more men and fewer months »“More Software projects have gone awry for lack of calendar time than for all other causes combined” -Fred Brooks

Slide TMMM.9/28 Why is adding people late bad? There are three reasons for this: –The work and disruption or repartitioning jobs –The time consumed training new people –The added intercommunication between people »There is a [n(n-1) / 2] increase in effort

Slide TMMM.10/28 Architecture vs. Implementation Keeping the “what” separate from the “how” Conceptual Integrity –It is better to eliminate some frills and functionality to preserve the design ideas than to use “many good but independent and uncoordinated ideas”

Slide TMMM.11/28 Aristocracy vs. Democracy Who is in control of design? What happened on OS/360? –10 Architects vs. 150 Implementers –The architecture manager said it would take his 10 good men 10 months to write the specifications, 3 months over the schedule –The control program manager said the 160 men could finish the specifications on time, and wouldn’t have the 150 implementers “twiddling their thumbs for 10 months”

Slide TMMM.12/28 Woops! Despite the architecture manager’s warnings Brooks had all 160 men do the specifications –The work was still 3 months late and it was of much lower quality than it could have been –The conceptual integrity was breached and the cost of the system went up –An estimated extra year of debugging took place

Slide TMMM.13/28 The Surgical Team Surgeon Administrator Secretary Editor Secretary Copilot Programming Clerk Tool-smith Tester Language Lawyer

Slide TMMM.14/28 System Debugging Debug the components before the system –Even using a component that has a known bug can cause unpredictable, and unusable results in system debugging Use scaffolding –“Dummy components” – a.k.a. stubs Replacing a debugged, working component with a newer debugged, working component does not mean you can skip testing!

Slide TMMM.15/28 Two Steps Forward and One Step Back

Slide TMMM.16/28 Documentation What is required? –How to use the program –Why to believe the program –How to modify the program Self-Documenting Programs

Slide TMMM.17/28 What has changed? Some things changed due to technology making some techniques mentioned obsolete –Documentation –Workstations –WWW –Disk space and memory Brooks did change his mind on the subject of information hiding proposed by Parnas

Slide TMMM.18/28 Information Hiding The idea that development is improved by hiding the technical details of the separate pieces of the system On what Brooks originally called a “recipe for disaster” he now writes: “I have been quite convinced otherwise by Parnas, and totally changed my mind.”

Slide TMMM.19/28 Waterfall vs. Incremental Must be able to “swim upstream” Harlan Mills’ incremental development model –A.K.A. the spiral model

Slide TMMM.20/28 So what’s the point? The practices of the software engineering community have changed very little over the last 30 years, and the mistakes being made then are still being made today.

Slide TMMM.21/28 No Silver Bullet “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity in reliability, in simplicity.” - Fred Brooks

Slide TMMM.22/28 Why is this? Past advancements such as high level languages haven’t been on the essence of development: –Complexity –Conformity –Changeability –Invisibility

Slide TMMM.23/28 Hopes for the silver bullet Object Oriented Programming and Design –Why does it fail? Large Scale Reuse –Why should we make what we can buy instead?

Slide TMMM.24/28 Brad Cox “The innovation is a paradigm shift, redefining what it means, or better what it should mean, to say we buy, sell, or own objects made of bits.” Which is more complex? –A pencil –Microsoft Word Version 3.1

Slide TMMM.25/28 Brad Cox Microsoft Word Version 3.1 –8 programmers (not counting documentation and testing) A pencil –Timber from California and Oregon –Graphite imported from Ceylon –Clay from Mississippi –Candelilla wax imported from Mexico –Lacquer produced

Slide TMMM.26/28 Analysis The very high cost of “manufacturing” reusable components which contributes to the already slow paradigm shift means that this wont be a revolution In the long run I agree with Brooks’ assessment that the process of improving development is going to be a slow evolutionary process, and not the revolution everyone keeps hoping for

Slide TMMM.27/28 Resources Frederick P. Brooks Jr. The Mythical Man-Month. Addison- Wesley, 1995 Brad Cox, No Silver Bullet Revisited, Information on Fred Brooks,

Slide TMMM.28/28 The Mythical Man-Months The End