Chapter 1 “The Tar Pit”
Pg. 4 In software development, no one thing seems to cause the difficulty, but the accumulation of simultaneous and interacting factors brings slower and slower motion.
Pg. 5 Developing a professional system is 9 times the cost and time of an amateur development of the same system.
Joys of programming:
Sheer joy of making something.
Making something useful.
Fascination of putting together a puzzle.
Working is such a creative and abstract medium.
Woes of programming:
One must perform perfectly.
Other’s set a programmers objectives, resources, information. Disjoint is responsibility and authority.
Dependence on other’s work which is often mal-designed, poorly implemented, incompletely delivered and poorly documented.
Debugging is drudge work.
Testing drags on and on, finding the last bug is harder than the first.
Product seems to be obsolete upon completion. However, something that is available is better than something planned.
Chapter 2 “The Mythical Man-Month”
Pg. 14 Most project go awry for lack of calendar time. Estimating time is difficult and tools are poorly developed and reflect the assumption that all will go well. There is always time to do something over and over again but not enough time to do it right. Effort and progress are confused as if men and months are interchangeable. When schedules slip the natural and worse response is to add manpower.
Pg. 15 Programmers are optimists. They design systems in “thought-space” a very flexible medium. However implementation reveals that our ideas are faulty but we blame the physical medium because of pride; we have bugs; hence our optimism is unjustified.
Pg. 16 Men and month are only interchangeable when tasks can be partitioned among workers and no communication among them is needed; woefully untrue of system programming.
Pg. 18 Communication made up of two parts: training and intercommunications. Training (technology, goals, overall strategy and work plan) can not be partitioned; more effort does no good. Intercommunications is worse, effort increases as n(n-1)/2. The more workers the more sets of pairwise interactions.
Pg. 19 Testing and debugging usually the most underestimated because of optimism. This usually occurs at the end of the schedule; it is bad news, late and without warning. This also occurs when project is fully staffed thus the daily expense is at its maximum.
Pg. 21 Desired completion time cannot govern actual completion time. This must be understood and accepted, trying to violate this will result in nothing. Can’t cook an omelette is the desired time; if tried you get it raw.
Pg. 23-26 Don’t throw manpower at the problem of schedule slippage. Increase the schedule time. As a schedule slips so does quality and features. The number of month is dependent on the sequential constraints, the maximum number of men depends upon the number of independent subtasks.
Chapter 3 “The Surgical Team”
The problem: small teams are best but sometime there is so much work that even a small team will take to long to accomplish the project. What to do?
Mill’s Proposal: Several small teams each working on a separate segment of the project. The teams are organized as a surgical unit – one surgeon with a support staff.
The surgeon is the chief programmer – designs, codes, documents, tests. Needs great talent and lots of experience.
The co-pilot is the backup chief programmer – works with the chief to help in thinking, etc… ready to take charge but not responsible for anything.
The administrator handles all the personnel matters based on the decision of the chief programmer.
The editor polishes the documentation that must be written by the chief programmer so that accuracy is achieved.
The system support person
The coders – small, very specific implementation programming tasks
Note this team structure is NOT a partnership; the chief programmer is it all with helpers who obey.
This means the project is of one mind and intercommunications and design decision and compromises are minimized.
On large projects the chief programmers of the surgical teams must communicate. An overall systems architect must arbitrate between all the teams.
Chapter 4 “Aristocracy, Democracy, and System Design”
Pg. 42 Software conceptual disunity is usually due to the separation of design into many tasks done by many people; not be a serial succession of master designers. Conceptual integrity is the most important consideration in system design. It is better to have fewer anomalous features and improvements, but one set of design ideas than to have many good but independent and uncoordinated ideas.
Pg. 43 This raises some issues which are addressed next.
Achieving conceptual integrity:
Functionality is at war with simplicity, a delicate balance must be struck. Conceptual integrity dictates that design must proceed from one mind, or from a very small number of agreeing resonant minds. Yet, many hands are needed to do all the work. This dilemma can be resolved with two techniques.
1. A careful division of labor between architecture and implementation.
2. The surgical team.
A large system is going to be more successful being mostly a aristocracy of architects than a democracy of architects and implementers. Implementers can contribute ideas but that must be consistent with the conceptual integrity. Architects should be mindful of known techniques of implementation that can be used to implement their designs.
Discipline and limits can be very helpful in the creative process; it provides needed form.
This chapter discusses in detail the arguments of architects vs. implementers and common objections.
I think we will need a small architecture team that will design a new billing system. Some of the people on this team will continue as architects once implementation starts in earnest but the other will become implementers.
Chapter 5 “The Second-System Effect”
To deal with the problem of the architect doing to much “blue-sky” design the architects and builders must be in thoroughgoing, careful, and sympathetic communications. Deal with people’s pride and emotion carefully when crossing boundaries.
Be careful not to under design the first system because this often leads to over designing the second system.
Second system design often falls prey to refining functionality that is contrary to the basic assumptions of the system. In other words, much work is done to make something really good but because the basic way of doing things has changed the effort is wasted. For example, fine tuning a batch debugging system when interactive computing was breaking onto the scene.
Solutions: assign costs and benefits to each function so that improvements can be properly evaluated. Have self-discipline in system design, be aware of the special temptations.
Chapter 6 “Passing the Word”
How can a group of 10 architects maintain the conceptual integrity of a system which 1000 people are building?
The written specification is a necessary but not a sufficient tool. The specification should describe the users needs but not implementation details. However, the architect should always be prepared to show an implementation for any feature described but not dictate the implementation. The specification must be precise, full and accurately detailed even at the cost of being boring.
A formal definition and a prose definition may be used to describe a specification, but one must be the standard and the other the derivative.
Formal meetings are held with the architects and representatives of the implementers. Additions and changes to the project are proposed by anyone, usually in writing beforehand. Discussion ensues with a bent towards getting multiple solutions and the deciding on the best. The chief architect arbitrates are deadlocks by making the decision. This information is disseminated to all.
To deal with issues that the formal meetings don’t address satisfactorily, problematic decisions, disgruntlements a type of supreme court session is held. Everyone is heard and everyone better understands the intricate constraints and interrelationships among decisions.
Multiple implementations being built at the same time serves as a mechanism to avoid the easy way out of just changing the specification when the specification and an implementation doesn’t agree.
A diary of events, questions and answers resolving specification and implementation issues should be kept and disseminated so that minor issues are clarified. Implementers shouldn’t remain puzzled about details and just guess at an answer an proceed, they should ask the architects and the discussion should be reflected in the diary.
The test group should be an independent, devil’s advocate group that keeps the developers true to the specification. This group must be involved early in the design. Care must be taken to mitigate this group and the developers because of the adversarial relationship.
Chapter 7 “Why Did the Tower of Babel Fail?”
For a project not to fail there needs to be lots of communication. Problems will arise due to subtle changes in assumptions among the different teams about the project specification. Regular, good communication needs to occur to ferret out these changes and resolve issues. Regular technical briefing meetings are invaluable – many minor misunderstanding get revealed and resolved by this means. Another major form is the formal project workbook. See the article for details about the what, why and mechanics of the workbook. The job done least well by project managers is to utilize the technical genius who is not strong on management talent. See chapter 18 item 7.14 & 7.15.
Chapter 8 “Calling the Shot”
Small project time estimates do not linearly scale to provide estimates for larger projects; it is more of an exponential scale. Some studies yielded a function of: effort = (constant) * (# of instructions)1.5
Another study revealed that estimates were off by one-half (projects taking twice as long as estimated) because only 50% of time thought to be for programming was actually for programming. The other 50% was accounted for by machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time.
Chapter 9 “Ten Pounds in a Five-Pound Sack”
Consider overall impact of particular strategies. What may be the “best” thing to do in one place may cause a larger problem overall; thus suboptimization must take a back seat to overall system optimization. A total-system, user-oriented software development attitude should be fostered. Remember data representation is the essence of programming. “Show me your flowcharts and conceal your data, and I shall continue to be mystified. Show me your data, and I won’t usually need your flowchart; they’ll be obvious.”
Chapter 10 The Documentary Hypothesis
There is a set of documents that are useful in many diverse settings (hardware product, software, university department, etc…). These documents describe the: what, when, how much, where and who of a project. They are titled in a generic sense as Objectives, Specifications, Schedule, Budget, Space allocation and Organization chart. Documentation is needed to make clear, exact policies because writing them down forces hundreds of mini-decisions to be made. Furthermore, documentation acts as a vehicle to communicate decisions to others. “This small set of critical documents encapsulates much of the manager’s work. If their comprehensive and critical nature is recognized in the beginning, the manger can approach them as friendly tools rather than annoying busywork. He will set his direction much more crisply and quickly by doing so.”
Chapter 11 Plan to Throw One Away
Build a pilot system and plan to throw it away. Then redesign and rebuilt and deliver that to the customer, never the throwaway system. You will always have a throwaway system; it’s not an option. Plan for and embrace change instead of fighting it; it is inevitable. The organization needs to be able to handle change. An organization that is critical of decision will cause decision-makers not to make decisions; an atmosphere of encouragement and creativity must be fostered so that people are willing to take risks. Just because you are a senior/valuable person doesn’t mean you should not write programs, you should. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence. Therefore, plan to rebuild at a future date.
Chapter 12 Sharp Tools
Refers mostly to old technology, these things have been adopted, enhanced and surpassed by today’s development environments.
Chapter 13 The Whole and the Parts
Eliminate bugs by doing good specification writing, have non-programmers test the specification, use step-wise refinement with top-down design and structured programming techniques. When doing system tests, use debugged components, provide lots of testing scaffolding, control changes, add components one at a time and schedule updates. Updates should be either large and very far apart or very small and frequent.
Chapter 14 Hatching a Catastrophe
Schedules slip one day at a time. However, we must have schedules. Setting schedules is a matter of experience. Furthermore note that 90% of the code is done half the time, 99% of the debugging is done most of the time. Meaning that the last little bit of these tasks take the most time because the hardest part is usually left until the end. Have milestones that are unambiguously defined, not temptation is soften bad news by deceiving. There will be problems and delays, plan for them – be pessimistic and conservative. Get concerned about small slips in time, fix the problems. Some of the ideas in this chapter seem out-dated. Problems should be reported to the boss but the boss should be wise in when to take action and when to just be educated on the status. A boss who acts appropriately will get honest appraisals of problems and status.
Chapter 15 The Other Face
Instill the practice of good documentation by showing good documentation not just exhorting that it be done. There is documentation for users and documentation for programmers. Flow-charting is obsolete, it has been since high-level languages were introduced.
Chapter 16 No Silver Bullet – Essence and Accident
Now is the time to start concentrating on improving the effort spent of the essence, not the accidents of software engineering. The essence is the fashioning of the complex conceptual structures that compose the abstract software entity. The accidents are representing the abstract entities in a programming language and the mapping to machine language within speed and space constraints. Much work has been done to improve productivity concerning the accidents of software engineering. To improve productivity about the essential parts of the software task do:
Buy instead of build.
Use rapid prototyping as part of a planned iteration in establishing software requirements.
Incrementally and iteratively develop software; grow it.
Develop great designers.
No silver bullets for software. Hardware advances are the anomaly in technology in the history of civilization.
The essence of a software entity is a construct of interlocking concepts: data, relationship among data items, algorithms and invocation of functions. The errors are in correctly specifying systems that solve a problem domain. This will always be hard so therefore software will always be hard.
The inherent properties of the irreducible essence of modern software are: complexity, conformity, changeability, and invisibility.
Software doesn’t usually have a repetition of the same element in a larger size, but an increase in the number of different elements. This causes complexity to increase for than linearly. Complexity causes communication problems and makes understanding the whole system impossible. This leads to all the typical software problems of over-schedule and over-budget, etc…
Software must conform to all the different systems it must interface with. This is complex because different people did the other systems; there is no central designer. This adds to complexity because making software conform often seems arbitrary and no amount of redesign will help the situation.
Software is more easily changed and gets changed more often in the field. One of the problems is not everyone understands the cost of the change as they understand the cost of changing a building already built.
Software has no geometrical shape and is thus unvisualizable. The graphs used to describe software are not hierarchical, nor even planar; the software is too complex. This impedes the process of design in a developers mind and much more in communicating ideas to others.
Accidental difficulties solved with high-level programming languages, time-sharing systems with faster turnaround time, IDE’s.
Ada, OO, AI, Expert Systems, Automatic programming, Graphical programming, Program verification all contribute a bit to the accidental problems of software construction but are no silver bullet for attacking the essence of software construction.
Promising attacks on the conceptual essence are build vs. buy (buy it if you can), requirements refinement and rapid prototyping (do prototyping to help determine system requirements), and incremental development (grow not build software). Foremost, great designer should be sought, compensated and retained.
Chapter 17 No Silver Bullet Refired
Complexity is the most serious difficulty, but oftentimes complexity is software arises from trying to model the complex realities of the malfunctions of an organization. The malfunctioning business processes of an organization should be fixed before modeling it in software. The details must be specified exactly and not statistically. Complexity also stems from software implementation, data structures, algorithms, and connectivity. Thus, software should be built upon other work; grown. Focus on quality of specifications, design and implementation and productivity will follow, but don’t do quality in the extreme or productivity will suffer greatly. Apply quality to avoid major disasters.
Chapter 18 Propositions of the Mythical Man-Month: True or False?
A summary of the chapters, stating the true assertions with updated comments.
Chapter 19 The Mythical Man-Month after 20 Years
Conceptual integrity is central to product quality; must have one system architect or if a large system, one master architect and one architect per subsystem. The subsystem boundaries must be at those places where interfaces between subsystems are minimal and easiest to define rigorously. Separate the task of the architect from that of implementation, plenty of work on both sides. The “throw the first one away” proverb is wrong. It is wrong because it implicitly assumes the waterfall method. The iterative and incremental model should be used. However, it should be known that the first iteration will not be fielded, so in this narrow sense the “throw the first one away” does still apply.
Projects should be organized with the architect as the top decision maker. Project management issues that are essentially administrative should be delegated to the architects “right-hand man”. A clear separation of the architect, implementers and problem domain experts should be made. Person of the right education, knowledge and skills should be placed in each of these positions. A person in a position gives answers to questions that are properly within that domain of responsibility. They give suggestions to other domains. The lead person for a software development project should be well versed in software engineering and constructions, not just someone who has managed other projects (typically not software projects).