“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.”

seja na definição do âmbito da nossa profissão, da matéria com a qual trabalhamos e do que nos leva a gosta de trabalhar nela.

“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.”

É dificil sintetizar todo o livro numa palavra, mas sendo um livro mais ou menos de gestão de projectos, é também um livro de gestão de relações humanas e de constatação que o desenvolvimento de software mais do que um fim (o produto final) é um processo – “grow, not build, software”.
Apesar de estarmos cada vez mais acima nas camadas de abstracção que nos levam do hardware (porque todo o software ainda corre num hardware) até ao domínio de negócio que queremos “softwarizar” continua a ser verdade que:

“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 they almost 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.”

Torna-se por isso para mim cada vez mais claro que um projecto de desenvolvimento de software é um projecto onde não se consegue especificar concretamente o que vai ser feito e logo quanto tempo vai demorar a fazer e portanto quanto é que deve custar.

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

E com uma definição tão abstracta para algo que no fim vai ser muito concreto (n linhas de código) percebemos que um projecto que tem que assentar na confiança entre todos os participantes do projecto.
Note-se no entanto que esta confiança não tem a ver com a ideia de fé ou crença mas sim de confiança porque todos os dados disponiveis apontam para que as soluções optadas são as mais apropriadas. Certamente que haverá erros durante o processo mas estando todos os envolvidos no projecto a par das decisões e dos objectivos, esses erros não terão mais relevância do que a necessária para evitar que se repitam.

Para além da ideia de desenvolvimento incremental e da ideia clara que “the clients do not know what they want”, outro ponto importante que é referido tem a ver com o papel do gestor de projecto e a sua relação com as pessoas que está a coordenar.
Como acontece provavelmente em relação a todas as profissões, também no desenvolvimento de software, a definição de prazos e datas é uma espécie de luta entre quem define o tempo que as tarefas demoram (programador) e quem quer gerir os deadlines (gestor de projecto) como se o facto de se querer algo mais rápido fosse sinónimo de ser possivel ter algo mais rápido…

“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.”

Ou seja, em vez de números e datas à partida irrealistas mas com potencial “psicológico” para o nivel hierarquicamente superior e/ou clientes, é preferivel batalhar para ter datas fiáveis e por isso cada vez mais confiáveis.

Todos estes pontos parecem às vezes banalidades e/ou generalidades com que todos podemos concordar, mas como disse no inicio não é pelo facto de eu os conhecer que não sofri até agora na pele o efeito de cada um desses pontos…

• notas leitura: The Mythical Man-Month 1
• notas leitura: The Mythical Man-Month 2
• notas leitura: The Mythical Man-Month 3

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

Frederick P. Brooks

Share/Save

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

Share/Save

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

Share/Save

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

Share/Save