Pode parecer estranho mas acabei de ler um livro sobre tecnologia, melhor sobre desenvolvimento de software, que foi escrito há 33 anos.
Para além da eventual afinidade que poderia ter por ler um livro que tem exactamente a minha idade, a verdade é que o que me levou a ler o ‘The Mythical Man-Month’ foi o reconhecimento que muitas pessoas ainda hoje revelam sobre o livro.
‘The Mythical Man-Month’ é um conjunto de artigos escritos como resultado do desenvolvimento do sistema OS/360 e do reconhecimento do que correu menos bem ou mesmo mal e tentativa de explicação desses erros.
E a verdade é que, com muita pena minha, consegui rever uma grande parte da minha vida profissional aí reflectida… é triste saber que estou a repetir erros que foram identificados há 33 anos…
Continue reading →

capítulo 14 – hatching a catastrophe
pag. 154
“When one hears of disastrous schedule slippage in a project, he imagines that a series of major calamities must have befallen it. Usually, however, the disaster is due to termites, not tornadoes; and the schedule has slipped imperceptibly but inexorably.”
“Concrete milestones, on the other hand, are 100-percent events. (…) source coding 100 percent complete, keypunched, entered into disk library, debugged version passes all test cases. These concrete milestones demark the vague phases of planning, coding, debugging”

pag. 156
“But every boss needs two kinds of information, exceptions to plan that require action and a status picture for education. For that purpose he needs to know the status of all his teams. Getting a true picture of that status is hard.”

pag.158
“The project manager has to keep his fingers off the estimated dates, and put the emphasis on getting accurate, unbiased estimates rather than palatable optimistic estimates of self-protective conservative ones.”

capítulo 15 – the other face
pag. 165
“Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt a program for changes in circumstance or purpose.”

“To believe a program. The description of how it is used must be supplemented with some description of how one knows it is running. This means test cases.”
pag. 166
“1. Mailine cases that test the program’s chief functions for commonly encountered data.
2. Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work.
3. Barely illegitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.”

capitulo 16 – No Silver Bullet – Essence and Accident in Software Engineering
pag. 199
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other sofware systems. No other part of the work so cripples the resulting system if done wrong. No other part is so more difficult to rectify later.
Therefore the most important function that software builders do for their clients is ther iteractive extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and the almos never have thought of the problem in the detail that must be specified. Even the simple answer – “Make the new software system work like our old manual information-processing system” – is in fact too simple. Clients never want exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteraction between the client and the designer as part of the system definition.
I would go a step further and assert that it is really impossible for clients, event those working with software engineers, to specifiy completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product they are specifying.”

pag.200
“Incremental development – grow, not build, software”

pag.241
“The programmer delivers satisfaction of a user need rather than any tangible product”

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Frederick P. Brooks

capítulo 9 – ten pounds in a five-pound sack
pag. 100
“Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.”

capítulo 10 – the documentary hypothesis
pág. 111
“Why have formal documents?
First, writing the decisions down is essencial. Only when one writes do the gaps appear and the inconsistencies protrude. The act of writinh turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishs clear, exact policies from fuzzy ones.”

capítulo 11 – plan to throw one away
pag. 117
“… both the actual need and user’s perception of that need will change as programs are build, tested and used.”
pag. 118
“Quantization of change is an essential technique. Every product should have numbered versions, and each version must have its own schedule and a freeze date, after which changes go into the next version.”
“…the reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer’s reluctance to commit himself to the defense of decisions which he knows to be tentative.”
pag. 121
“Program maintenance involves no cleaning, lubrication, or repair of deterioration. It consists chiefly of changes that repair design defets.”
pag. 122
“… the total number of module increases linearly with release number, but that number of modules affected increases exponentially witn release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system…”
pag.123
“Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is as entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.”

capitulo 13 – the whole and the parts
pag. 142
“… conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs.”
pag. 144
“Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief”
pag. 147
“The unexpectedly hard part of building a programming system is system teste. (…) one should be convinced of two things: system debugging will take longer than one expects, and its difficulty justifies a thoroughly sysematic and planned approach.”

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Frederick P. Brooks

capitulo 1 – The Tar Pit
pag. 9
“The obsolescence of an implementation must be measured agaisnt other existing implementations, not against unrealized concepts. The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.”

capitulo 2 – The Mythical Man Month
pag. 15
“The programmer builds from pure thought-stuff: concepts and very flexible representation thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified.”
pag. 16
“Men and month are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”
pag. 21
“Observe that for the programmer, as for the chef, the urgency of the patron may govern the schedule completion of the task, but it cannot govern the actual completion.”
pag. 21
“It is very difficult to make a vigorous, plausible, and jobrisking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the manager.”
pag. 25
“The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men an fewer months. More software products have gone awry for lack of calendar time than for all other causes combined.”

capitulo 3 – The Surgical Team
pag. 30
“… if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming. (…) the problem with the small, sharp team concept [is] it is too slow for really big systems.”
pag. 33
“absolutely vital to [Harlan] Mills’s concept is the transformation of programming from ‘private art to public practice’ by making all the computer runs visible to all team members and identifying all programs and data as team property, not private property.”
pag. 35
“Notice in particular the differences between a team of two programmers conventionaly organized and the surgeon-copilot team. First, in the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work. In the surgical team, the surgeon and copilot are each cognizant of all the design and all of the code.”

capitulo 4 – Aristocracy, Democracy, and System Design
pag. 42
“Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.”
pag. 45
“By the architecture ofa system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language os languages used to invoke its functions. For the entire system it is the union of the manuals a user must consult to do his entire job.”
pag. 46
“Good features and ideas that do not integrate with a system’s basic concepts are best left out.”

capitulo 4 – the second-system effect
pag. 56
“The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendendy to refine techniques whose very existence has been made obsolete by changes in basic system assumptions.”

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Frederick P. Brooks