The Mythical man-month - Frederick P. Brooks jr.

• Efforts
• standalone program *3 to develop program that works on any system
• standalone program *3 to develop program to programming product which works with other programs
• standalone program *9 to develop program that works on all systems together with other programs
• Only this is a truly useful project
• Why is programming fun?
• Sheer joy of making things
• useful to other people
• we want others to use our work and find it helpful
• fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work
• Joy of always learning
• The programmer, like the poet, works only slightly removed from pure thought-stuff by exertion of the imagination
• Woes of programming
• One must perform perfectly
• other people set one's objective
• One rarely controls the circumstances of his work or even its goal.
• One's authority is not sufficient for his reponsibility
• (Here agile tries to bring responsibility and authority together)
• Designing grand concepts is fun; finding nitty little bugs is just work
• debugging has a linear convergence, the last difficult bugs taking more time to find than the first
• the technological base on which one builds is always advancing
• as soon as one freezes a design, it becomes obsolete
• implementation of real products demands phasing and quantizing. The obsolescene of an implementatino must be measured against other existing implementations, NOT against unrealized concepts
• (excecution is what counts)
• (better done than perfect)
• Good cooking takes time. If you are made to wait, it is to serve you better, and to please you
• More software projects have gone awry for lack of calendar time than for all other causes combined
• All programmers are optimists
• Perhapts the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal.
• So the first false assumption that underlies the scheduling of systems programming is that ALL WILL GO WELL, i.e. that EACH TASK WILL ONLY TAKE AS LONG AS IT "OUGHT" TO TAKE
• A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small
• Men and months are interchangeable commodities only when a task can be partitioned among many workers with NO communication among them
• The bearing of a child takes nine months, no matter how many women are assigned
• Many software tasks have this characteristic because of the sequential nature of debugging
• the effort of communication must be added to the amount of work to be done.
• The added burdon of communication is made up of two parts: training and intercommunication
• Each worker must be trained
• Intercommunicatino is worse - efforts increases as n(n-1)/2
• It quickly dominates the decrease in individual task time.
• Adding more people then lengthens, not shortens, the schedule.
• Therefore, testing is usually the most mis-scheduled part of programming
• 1/3 planning + 1/6 coding + 1/4 component test and early system test + 1/4 system test, all components at hand 
• 33% plan, 17% build, 50% test
• no one is aware of schedule trouble until almost the delivery date.
• delay at this point has unusually severy financial, as well as psychological, repercussions
• An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices . wait or eat it raw. Software customers have the same choices.
• What does one do when an essential software project is behind schedule? Add manpower naturally
• Or trim the task
• BROOKS LAW: "Adding manpower to a late software project makes it later."
• (therefore decompose tasks, small scopes - agile delivery = usable increments)
• Wide productivity variations between good programmers and poor ones
• 10:1
• The data showed no correlation whatsoever between experience and performance
• small, sharp teams max 10 people (this is exactly scrum team size)
• Most European cathedrals show differences in plan or architectural style between parts build in different generations by different builders. The later builders were tempted to "improve" upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. 
• Against these, the architectural unity of Reims stands in glorious contract. This integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design.
• 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.
• (Airport Berlin desaster with steadily changing scope)
• Similarly, I observe that the external provision of an architecture enhances, not cramps, the creative style of an implementing group. They focus at once on the part of the problem no one has addressed, and inventions begin to flow. In an unconstrained implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.
• "We finally decided to implement the language unchanged and unimproved, for the debates about language would have taken all the effort."
• The fundamental answer is thoroughgoing, careful, and sympathetic communication between architect and builder..
• An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing.
• An ancient adage warns, "Never go to sea with two chronometers, take one or three."
• He found his programming teams missing schedules by about one-half
• showed that the estimating error could be entirely accounted for by the fact that his teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority unrelated jobs, meetings, paperwork, company business, sickness, personal time etc accounted for the rest 
• In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year.
• "It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something." - Franklin D. Roosevelt
• In most projects, the first system build is barely usable. It may be too slow, too big, awkward to use, or all three.
• The management question, therefore, is not WHETHER to build a pilot system and throw it away. You WILL do that. The only question is wether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.
• Hence, plan to throw one away; you will, anyhow
• Managers themselves often think of senior people as "too valuable" to use for actual programming. Next, management jobs carry higher prestige. To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a "member of the technical staff"
• Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people
• Whenever talents permit, senior peope must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. 
• It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.
• We rebuild the developing system every night [and run test cases]. The build cycle becomes the heartbeat of the project. Every day one or more of the programmer-tester teams check in modules with new functions. After every build, we have a running system.
• In particular, adding extra manpower early in the schedule is a much safer maneuver than adding it later, since the new people always have an immediate negative effect.