The Mythical Man Month Essays on Software Engineering

The Mythical Man Month Essays on Software Engineering An Overview Presented by Prashant Kashyap FREDERICK P. BROOKS, JR Btech 2000

The tar pit n The Good ¡ n The Bad ¡ n Joys of programming Woes of programming The Ugly ¡ Systems integration is a punch in the face System programming has been such a tar pit – very Sticky !

The Mythical Man Month n What is the man-month? ¡ ¡ ¡ Cost varies as the product of the number 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 n It implies that men and months are interchangeable

The Mythical Man Month n “The bearing of a child takes nine months, no matter how many women are assigned” ¡ Software projects are sequential in nature. n n They generally consist of several steps that must be completed one after another These steps cannot be worked on at the same time. (un-partitionable)

The Mythical Man Month n n n Throwing more people at a software project has no real effect upon the date of project completion. In fact, the overheads, ¡ training ¡ preserving “conceptual integrity” ¡ communication paths may delay the project further. “Adding manpower to a late project makes it later. ” Why? The work and disruption or repartitioning jobs The time consumed training new people The added intercommunication between people n There is a [n(n-1) / 2] increase in effort

The Mythical Man Month Communication Paths 2 people, 1 channel 3 people, 3 channels 4 people, 6 channels N=n(n-1) 2 5 people, 10 channels 20 PEOPLE, 190 CHANNELS!

The Mythical Man Month

Surgical Team Problem: n n There is an order of magnitude difference between good programmers and bad programmers. More people working on a project = more miscommunication between those people ¡ Smaller groups are better, but a small group is too slow to create a large system in a reasonable amount of time.

Surgical Team Solution: n Miller’s Proposal: ¡ Break up the programming teams into smaller sub-groups, with only one or two people doing actual coding. Everyone else in the team acts as support for these people. Thus, only a limited number of minds need to coordinate ideas, which reduces communications problems.

Surgical Team the pilot supervisor Surgeon Administrator Secretary Editor Secretary documentation Copilot Programming Clerk Tool-smith Tester Language Lawyer the know-it-all guy

Aristocracy, Democracy, and System Design n Conceptual Integrity is the most important consideration in system design ¡ n “It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. Features Vs. Simplicity ¡ Where they balance is when ease of use is optimum.

Aristocracy, Democracy, and System Design n “If a system is to have conceptual integrity, someone has to control the concepts. ” ¡ ¡ ¡ Architect The architects are to become the aristocrats from whom all design decisions originate. The implementers are then the peasants, soldiers, builders, and thinkers that support the aristocrat’s ideas. Where architecture tells what is to happen, while implementation tells how it is to happen. Implementers

The Second-system Effect n n When a programmer works on a large system for the first time, he generally keeps things simple and to the point. Radical ideas, features, or innovative implementations he would like to try are filed away for later use. When a programmer works on his second large system, these files come out of storage with a vengeance. Great care must be taken to insure that the system design is adhered to by all team members.

Passing the Word n Manuals ¡ External specifications of the product (Product Manual) n ¡ Internal specifications of the product (System Manual) n n Describes every technical detail about the system that may be used by the implementers. Meetings ¡ ¡ n Describes everything the user sees, and nothing that he doesn’t see Weekly half-day conferences Annual or semi-annual “Supreme Court” meetings Email logs

The Fall of Babel … “…let us build ourselves a city with a tower whose top shall reach the heavens…”… then the Lord came down. . . said “Come, let us go down, and there make such a babble of their language that they will not understand one another’s speech. ” And thus the Tower of Babel was left incomplete.

The Fall of Babel n n n When people lost the ability to communicate with one another, they could no longer work together to complete the Tower of Babel. Likewise, when communication is lost to a software development team, the project they are working is doomed as well. Combative measures ¡ ¡ ¡ Informal email / telephone service Regularly scheduled meetings Project Workbook

Calling the Shot n Programming effort is a function of program size. ¡ ¡ ¡ Naturally, the larger and more complex the program, the longer it takes to complete However, this relationship is not linear. It’s an exponential growth function. Effort = (constant) x (number of instructions)

Calling the Shot Man-months incomplete Thousands of machine instructions

Ten Pounds in a Five Pound Sack n n Program space (memory) is a cost Thus size control is important Two methods to control size: space control and data representation Space techniques ¡ ¡ n Trading function for size Space - time tradeoffs (CPU power) Representation techniques ¡ Efficient data representation (objects, data structures)

The Documentary Hypothesis n Reasons for having formal documents ¡ ¡ ¡ Recording decisions Communicating those decisions Data base / checklist (programmer directives)

Plan to Throw One Away n n "The throwaway is the acceptance of the fact that as one learns, he changes the design. " Pilot plants - upscale from small to large ¡ n Modern approach: 'alpha' and 'beta' testing Plan your system for change ¡ Modern approaches: n n pre release: code base / configuration managers (e. g. : Source. Safe) post release: patching systems Collapse of the aerodynamically misdesigned Tacoma Narrows Bridge 1940

Sharp Tools n n “A good craftsman is known by his tools. ” The tools of a programmer are: ¡ Target machines n ¡ Vehicle machines n ¡ The programmer’s work environment Data services n ¡ The final testing environment Compiler, assembler, libraries, debugging tools HLL & interactive programming n Language and programming tool of choice (e. g. : Java and JBuilder)

Hatching a Catastrophe n n Schedules are important to keep Give the team 100% certifiable milestones ¡ n Pay attention to schedule slipping ¡ n Clearly define what needs to be done Small slips can quickly compound into major project tardiness Under the employee rug ¡ ¡ ¡ There always manager-boss conflicts Minimize the conflict between you and your managers But occasionally, yank the rug out from under them

The Other Face n n Documentation is important to the user, as well What kinds of documentation do they need? ¡ ¡ ¡ n n How to use the product How the product works How to adapt the product to their needs Flowcharts are flawed: they can be easily represented with code comments Self-documenting programs ¡ Merge source code and documentation (wellcommented code)

The Whole and the Parts n Design the bugs out of the system ¡ ¡ n Bug-proof the definition Use structured programming Component debugging ¡ ¡ ¡ Test cases System debugging Use debugged components Scaffolding Control changes Add one component at a time

Exhaustive Testing. Really? n Simple loop, executing ≤ 20 times ¡ ¡ 1014 possible paths at 1 ms per test, would take 3170 years

No Silver Bullet- Essence and Accident in Software Engineering “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 n n “. . . building software will always be hard” due to difficulties in its intrinsic nature (essence); however, improved process can solve difficulties which surround software production and are not part of its nature (accidents)

No Silver Bullet: Difficulties in Essence of Software n complexity: due to interaction of components, number of possible states grows much faster than lines of code.

No Silver Bullet: Difficulties in Essence of Software n changeability: must model changing real world, increase functionality, run on new hardware.

No Silver Bullet: Difficulties in Essence of Software n conformity: must interface with existing systems.

No Silver Bullet: Difficulties in Essence of Software n invisibility: cannot visualize all aspects at once.

No Silver Bullet: Breakthroughs for improving the Accidents n n n software development environments use of “off the shelf” software and components rapid prototyping incremental development training, encouraging great designers aspects at once.

Some Methods for Dealing with Essential Difficulties n Complexity ¡ ¡ n Changeability and Conformity ¡ ¡ n Abstract models Breakdown of system into manageable modules Breakdown of development process into phases, tasks, and subtasks Team programming Change management Configuration management Invisibility ¡ use of multiple models, for many views of system

No Silver Bullet: Refired n What is accidental? ¡ Intent n ¡ Misunderstanding n n accidental: incidental or appurtenant accidental: occurring by chance, “Shrinking the accidental part to zero will not give an order of magnitude productivity improvement. ”

No Silver Bullet: Refired Complexity n Not all complexity is inevitable n “… Yesterday’s complexity is tomorrow’s order. ” n There are no general rules to avoid complexity n Complexity is by levels ¡ ¡ Complexity in software construct is due to implementation rather than conformity to the external world. Solution n n Hierarchically, by layered modules or objects Incrementally, so that the system always works

No Silver Bullet: Refired n Harel’s “Gloom” themes ¡ “Sharp separation into essence and accident” ¡ “Treatment of each silver bullet candidate in isolation” ¡ “Predicting for only 10 years, instead of a long enough time in which ‘to expect any significant improvement’”

No Silver Bullet: Refired n Productivity Follows Quality ¡ ¡ ¡ n “Focus on quality, and productivity will follow. ” - Jones’s view “… productivity drops again as one pursues extreme quality…” - Boehm’s view “… systematic software development disciplines were developed in response to quality concerns … rather than productivity concerns. ” - Coqui’s view What has happened to productivity? ¡ ¡ ¡ Measuring productivity is difficult Shrink-wrapped software - Buy; don’t build Tools improve productivity n cheap, powerful tools that are easy to use

No Silver Bullet: Refired n What about REUSE? ¡ ¡ Don’t build software. Aims n n n Programmer level - 30% Corporate level - 75% How does corporate-level reuse fare today? - Jones n n Large companies have reuse research Small companies don’t “Reuse is something that is far easier to say than to do. ” - Parnas

No Silver Bullet: Refired CONCLUSION n Complexity ¡ n Productivity ¡ n Cannot do away with completely Focus on Quality and it will lead to productivity Reuse ¡ Don’t reinvent the wheel

The Mythical Man-Month after 20 Years n We, the programmers, pledge not to ask the presenter of this presentation about this! We UNDERSTAND where it stands. n Game for a Discussion? (not me )

References 1. 2. 3. 4. 5. 6. 7. 8. The Mythical Man Month – Fredrick P. Brook’s Jr. , Pearson Education Asia Publishers. Software Engineering – A practitioner’s Approach by Roger S. Pressman Software Project Management (Lecture)- Peking University, Fall Semester, 2001 No Silver Bullet : Essence and Accident in Software Engineering by Prof. Fred Brooks, IEEE Computer, April 1987 Frederick P. Brooks Jr. The Mythical Man-Month. Addison. Wesley, 1995 Brad Cox, No Silver Bullet Revisited, http: //www. virtualschool. edu/cox/Am. Pro. TTEF. html Information on Fred Brooks, http: //www. cs. unc. edu/Events/News/Turing. Award. html Ed Yourdon, Managing Projects to Produce "Good Enough" Software, http: //www. yourdon. com/articles/9503 ieee. html