This is a very old book. It talks about lessons learned from working on an operating system for an IBM mainframe in mid sixties. It was a large project involving thousands of people and many years. Times have changed and our projects are much smaller, but there is still few things to learn. BTW. Somebody should update this book, or at least add footnotes translating ancient technical terms to todays language, e.g. is "control program" an OS? Is "language translator" a compiler? Does "producer" mean project manager? etc... My comments/opinions (not coming from the book) are marked JS. Corrections, additions and comments (to my comments) are welcome. ----------------------------------------------------------------------- When programmers give estimates they only include writing code, they do not include testing, documentation, integration, etc - you have to multiply that number by a factor, e.g. 9 Joys of programming: - making things - making things useful to others - solving puzzles - learning - creating from imagination/mind/thought - like magic - gratifies creative longings Woes: - requires perfection (one mistake and the magic doesn't work) - most human activity does not require it - some people include that in joys - it's a job - you do what others want, with their resources - dependence on others (buggy, poorly documented programs, no source) - designing grand concepts is fun, details are not - debugging is linear (while people expect it to be quadratic) - sometimes the product is obsolete on or before completion (competition, better ideas) Most estimates: - are poorly developed - include unvoiced assumptions - assume that all will go well (programmers are optimists) - confuse effort with progress (assuming that men and months are interchangeable) - because of uncertainty, people fail to insist on taking the time - progress is poorly monitored - when it slips, they add people = dousing a fire with gasoline Creative activity: - idea - implementation - interaction (consumption by end user) We don't usually find problems until phase 2. They are: - limitations of the media - inadequacies in the idea We usually blame the media (pride colors our judgement) The more complex the project, the less probability that all will go well. Man-month can be used to measure cost, but not the progress (or size of the job) Man and month are interchangeable only when there is no need to communicate between them, and all tasks can be done in parallel e.g. picking cotton. The bearing of a child takes nine months, no matter how many women are assigned. Communication: - training (cannot be partitioned - varies linearly with number of people) - technology - goals - strategy - plan - intercommunication - if each task must be coordinated with each other, the effort increases as n(n-1)/2 - if there is need for conferences among 3, 4, ..., it get even worse, until adding people lengthens the schedule Rule of thumb schedule: - 1/3 planning - 1/6 coding - 1/4 component test and early system test - 1/4 system test Brooks's Law: Adding manpower to a late software project makes it later. More software projects have gone awry for lack of calendar time than for all other causes combined. There are large individual differences between high and low performers, often by an order of magnitude. Small team, even if 50 times more productive than average, cannot deliver large system in a reasonable amount of time (would have to be 500 times). Surgical Team: - chief programmer (surgeon) - defines spec, designs, codes, tests, documents - copilot - alter ego of the surgeon - shares in the design, knows the code, researches alternative designs, may even write code - 8 supporting persons: administrator, editor, 2 secretaries, clerk, toolsmith, tester, language guru (JS: This may have changed from the 60s) Ease of use is enhanced only if the time gained in function exceeds time lost in learning. Conceptual integrity is the most important consideration in system design. It determines the ease of use. Design must proceed from one mind or from a very small number of agreeing minds. Architecture should be separated from implementation. Architecture = complete and detailed specification of the user interface. Architect is the user's agent. Second-System Effect People working on their second system tend to solve their first-system issues. Never go to sea with two chronometers; take one or three. The purpose of organization is to reduce the amount of communication and coordination necessary. It is done by: - division of labor - specialization of function Effort is proportional to the power of program size: effort = constant x number_of_instruction (to the power of) 1.5 Only 50% of the working week is actual programming/debugging. The rest is downtime, short term tasks, meetings, paperwork, company business, sickness, personal time, etc. Good manager will make sure that his team is trained in the technologies they will be using. Way to improve program: - better algorithms - better data representation Throw one away - in most projects, the first version is barely usable (particularly when new concepts or technologies are used). Delivering that throwaway to customers may not be a good idea. Programmer delivers satisfaction of a user need (rather than any tangible product). Both the actual need and user's perception of that need will change with time. Design should change as the project progresses. Why people don't like design and documentation: By documenting a design, the designer exposes himself to the criticism of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop the the rescue wherever battle is thickest. Management jobs carry higher prestige. To overcome this problem some laboratories like Bell Labs, abolished all job titles - each professional employee is a "member of the technical staff". Others, like IBM, maintain a dual ladder of advancement - technical and managerial, with the same salary scales. To keep the same prestige, offices have to be equal size and appointment, secretarial and other services must correspond. Managers should be sent to technical refresher courses, senior technical people to management training. Senior people should be allowed to write code. Maintenance = repairing design defects. Maintenance cost = 40% of development cost (or more). Fixing a defect has a substantial (20-50%) chance of introducing another - two steps forward, one step back. As a result, it requires more testing (regression testing). Repairs tend to destroy the structure, to increase the entropy and disorder of the system, until number of fixes = number of new bugs - one step forward, one step back - from-the-ground-up redesign is necessary. Each team should have a toolmaker - master of tools, maintainer and teacher. To get honest status reports, the boss must accept status reports without panic or preemption. Flow charts are obsolete and useless. Use self-documenting code - function and variable names, layout, etc Comment only what is not obvious.