the mythical man month essays on software engineering

The Mythical Man Month Essays on Software Engineering Presented byPrashant KashyapBtech 2000FREDERICK P. BROOKS, JRAn Overview

The tar pitThe GoodJoys of programmingThe BadWoes of programmingThe UglySystems integration is a punch in the faceSystem programming has been such a tar pit very Sticky !

The Mythical Man MonthWhat is the man-month?Cost varies as the product of the number men and the number of monthsProgress does notHence the man-month as a unit for measuring the size of a job is a dangerous and deceptive mythIt implies that men and months are interchangeable

The Mythical Man MonthThe bearing of a child takes nine months, no matter how many women are assignedSoftware projects are sequential in nature.They generally consist of several steps that must be completed one after anotherThese steps cannot be worked on at the same time. (un-partitionable)

The Mythical Man MonthThrowing more people at a software project has no real effect upon the date of project completion. In fact, the overheads, trainingpreserving conceptual integritycommunication pathsmay delay the project further.

Adding manpower to a late project makes it later.Why?The work and disruption or repartitioning jobsThe time consumed training new peopleThe added intercommunication between peopleThere is a [n(n-1) / 2] increase in effort

The Mythical Man Month20 PEOPLE, 190 CHANNELS!Communication Paths

The Mythical Man Month

Sheet:

Sheet:

Sheet:

Sheet:

Surgical Team

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

Surgical Team

Millers 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.Solution:

Surgical Teamthe pilotdocumentationthe know-it-all guy

Aristocracy, Democracy, and System Design Conceptual Integrity is the most important consideration in system designIt 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. SimplicityWhere they balance is when ease of use is optimum.

Aristocracy, Democracy, and System DesignIf a system is to have conceptual integrity, someone has to control the concepts.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 aristocrats ideas.Where architecture tells what is to happen, while implementation tells how it is to happen.ArchitectImplementers

The Second-system EffectWhen 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 WordManualsExternal specifications of the product (Product Manual)Describes everything the user sees, and nothing that he doesnt seeInternal specifications of the product (System Manual)Describes every technical detail about the system that may be used by the implementers.

MeetingsWeekly half-day conferencesAnnual or semi-annual Supreme Court meetingsEmail 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 anothers speech. And thus the Tower of Babel wasleft incomplete.

The Fall of BabelWhen 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 measuresInformal email / telephone serviceRegularly scheduled meetingsProject Workbook

Calling the ShotProgramming effort is a function of program size. Naturally, the larger and more complex the program, the longer it takes to completeHowever, this relationship is not linear. Its an exponential growth function.Effort = (constant) x (number of instructions)

Calling the ShotThousands of machine instructionsMan-monthsincomplete

Ten Pounds in a Five Pound SackProgram space (memory) is a costThus size control is importantTwo methods to control size: space control and data representationSpace techniquesTrading function for sizeSpace - time tradeoffs (CPU power)Representation techniquesEfficient data representation (objects, data structures)

The Documentary HypothesisReasons for having formal documentsRecording decisionsCommunicating those decisionsData base / checklist (programmer directives)

Plan to Throw One Away"The throwaway is the acceptance of the fact that as one learns, he changes the design."Pilot plants - upscale from small to largeModern approach: 'alpha' and 'beta' testingPlan your system for changeModern approaches:pre release: code base / configuration managers (e.g.: SourceSafe)post release: patching systemsCollapse of the aerodynamically misdesigned Tacoma Narrows Bridge1940

Sharp ToolsA good craftsman is known by his tools.The tools of a programmer are:Target machinesThe final testing environmentVehicle machinesThe programmers work environmentData servicesCompiler, assembler, libraries, debugging toolsHLL & interactive programmingLanguage and programming tool of choice (e.g.: Java and JBuilder)

Hatching a CatastropheSchedules are important to keepGive the team 100% certifiable milestonesClearly define what needs to be donePay attention to schedule slippingSmall slips can quickly compound into major project tardinessUnder the employee rugThere are always manager-boss conflictsMinimize the conflict between you and your managersBut occasionally, yank the rug out from under them

The Other FaceDocumentation is important to the user, as wellWhat kinds of documentation do they need?How to use the productHow the product worksHow to adapt the product to their needsFlowcharts are flawed: they can be easily represented with code commentsSelf-documenting programsMerge source code and documentation (well-commented code)

The Whole and the PartsDesign the bugs out of the systemBug-proof the definitionUse structured programmingComponent debuggingTest casesSystem debuggingUse debugged componentsScaffoldingControl changesAdd one component at a time

Exhaustive Testing. Really?Simple loop, executing 20 times1014 possible pathsat 1 ms per test, would take 3170 years

No Silver Bullet- Essence and Accident in Software EngineeringThere 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

... 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 Softwarecomplexity: due to interaction of components, number of possible states grows much faster than lines of code.

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

No Silver Bullet:Difficulties in Essence of Softwareconformity: must interface with existing systems.

No Silver Bullet:Difficulties in Essence of Software

invisibility: cannot visualize all aspects at once.

No Silver Bullet: Breakthroughs for improving the Accidents

software development environmentsuse of off the shelf software and componentsrapid prototypingincremental developmenttraining, encouraging great designersaspects at once.

Some Methods for Dealing with Essential DifficultiesComplexityAbstract modelsBreakdown of system into manageable modulesBreakdown of development process into phases, tasks, and subtasksTeam programmingChangeability and ConformityChange management Configuration managementInvisibilityuse of multiple models, for many views of system

No Silver Bullet: RefiredWhat is accidental?Intentaccidental: incidental or appurtenantMisunderstandingaccidental: occurring by chance,

Shrinking the accidental part to zero will not give an order of magnitude productivity improvement.

No Silver Bullet: RefiredComplexityNot all complexity is inevitable Yesterdays complexity is tomorrows order.There are no general rules to avoid complexityComplexity is by levelsComplexity in software construct is due to implementation rather than conformity to the external world.SolutionHierarchically, by layered modules or objectsIncrementally, so that the system always works

No Silver Bullet: RefiredHarels Gloom themesSharp separation into essence and accident

Treatment of each silver bullet candidate in isolation

Predicting for only 10 year