I watched the Fred Brooks keynote that I blogged about, and here are my unedited notes:

Brooks invented the term “computer architecture”.

one programmer, two, ... many programmers. creeps up on you … the consequences

as your teams get larger, there’s no alternative to putting in process and control – HOW to put in without stifling creativity

process, control, and how to preserve cretivity

solo programming, easy to manage. one mind designing things. conceptual integrity. all in your mind … changes … you can get by as long as you continuously program – without documenting. if you put it away you’ll not remember it.

extreme programming – pair programming. Brooks thinks it’s great. 2 programmers working as 1. can produce more than working separately due to lower error rate. laurie williams study. a pair of people 15% person hours than one person doing the same job. 1-2 orders of magnitude fewer defects – finding bugs, fixing bugs, fixing bugs you put in when fixing the first bugs …

harlan mills suggested pair programming in 1971—brooks mentioned it in 1975 (in mythical man month)

in those days computing time was expensive so you only got one shots

from pairs to small teams (in the same place) teleconferencing is not the same as co-location, and may never be.

defining interfaces—more minds working on the problem

putting pieces back together … straightforward (not?)

two functions: (same in movie business, producer/director) manager/architect—even with teams of four: Brooks insists that two separate people: producer/director. producer – responsible for getting the job done; responsible for putting the resources together, negotiating with management, customers, etc. architect – responsible for technical integrity of the product; separating these roles, as they are full time jobs.

manager – vision. architect – design.

harlan mills proposes that for a small team 6-8 people: chief programmer, co-pilot that writes all code—pair programmer—the rest is support-people to support the others. conceptual integrity (reason). testing, documentation, interaction with code management process, etc—all supportive roles.

large teams: how large is large? more than 12? more than 20? is it a 100? OS360 1000 people i 8 locations of the world—too large (laughs). somewhere around 12 you have to split into subteams, with foremen, lead programmers—responsible for leading the subteams. 2 subteams & a manager for the whole thing—large team.

all interesting problems are large-scale problems. left chapel hill.

with the exception of OO, all the inventions are addressing the problems of scale and process.

message #1 – as you get to a large team, you have to have a formal methodology and means of control. turnover. communication among people who are there, and those who are no longer there. raise and formalize the level of documentation.

the hardest problem with a large team – how do you maintain the conceptual integrity of the product. making sure that all the decisions, micro-decisions, are made in a consistent way. why? the fundamental reason: one user, many builders – one user see one product. true for ease of learning, ease of routine usage for naive users and expert users. very important: try to figure out mechanisms for maintainging conceptual integrity.

the best mechanism brooks knows of: have an architect – chief technical designer – responsible for maintaining the conceptual integrity. of the user interface – what the user sees. same function as the architect of a building. an expert client. surrogate client. represents the client’s intrests. the users interests. “what is it the client really needs?” requires understanding clients, talking to clients.

formalize by writing down the assumtpions that are made of what the user’s doing. naive/expert users. writing this down is important and impossible from the point of view of getting it right. it’s better to be specific and wrong than vague in writing down this, because: if you’re specific and wrong, the other team members will challenge it—creates discussion. if it’s vague: everyone will read into it what they like. inconsistent set of ideas of the system—leads to poor conceptual integrity.

you can identify the assumptions … spend a little more determining whether the assumptions are good. 10% will turn out to be critical for the solution—but you don’t know which 10%.

the architect is a surrogate for the user, representative. expert, professional. user’s aren’t able to say what they want. imagination on the part of the architect.

the other function of the architect is to make sure that it makes sense of the point of view of ONE user. [anecdote about 800 page manual for a system; no one knew it all—how do you suppose the user should understand it all]

the internal structure: commonly intention when using the term “software architecture”.

#2: code control—cvs, check in/out, version control, etc. playpen copy, to try out things. etc. esp. in middle-sized teams the hard part isn’t (learning) the technology. 2, 3 – didn’t need it … 5, 8, you’re hurting more. the sooner you put it in, ....

#3 change control … formal – analogy of a school with curriculum changes: needs a change control mechanism to avoid confusion. deciding which changes to allow. some are harmless—the whole notion of information hiding, OO, is to define a class of changes that are by definition harmless—as they take place inside the classes. you own the inside and change it as you see fit. the interfaces are depended upon, so here changes must be controlled. inter-module where different people have different modules. control the interfaces for modules even if same person owns them all.

change control requires a consultative process (?) – put out proposed changes on green papers – put on desks, proposals; and – which takes a little longer – a person in charge of decisions. [OS360 anecdote … fall festivals, debate and make decisions, 2 weeks for 200 change proposals] a combination of consultation and a clear yes/no answer.

#4 documentation – formalizing. larger team, larger project → longer project. forgetting decisions you have made. most program documentation is too much line comments, too little paragraph headers, too much how it is done, too less WHY. why is especially important, as the code conveys what it does. why isn’t explained usually – it states what must be protected [unit tests covers this]

global documentation – of what a set of function does, is more important than local documentation. show me your code and conceal your data structures, lost → other way around, you can figure it out. docs usually describe the algorithm, not data structures. what are you trying to do is crucial to preserve.

internal documentation for your heirs. if you failed there will be no heirs.

#5 testing – an independent tester. someone who’s free of the assumptions of the programmers. so he/she tests other things. regression testing after changes. ever going bank of test cases, longer and longer. usability testing. batch is easier to test, interactive harder. networked/distributed even harder.

process discipline (is this #6?) why is s/w engineering is such a primitive state? in terms of productivity[?] civil engineering, bridge builders … [anecdote, went down to the machine room; shift changes, to debugging … independent debuggers … debugging at night … yellow wires] all these discipline may help but don’t ensure great design and great programming—head off trouble, but don’t give you great design. so how do you preserve creativity. great designs come from great designers. All that SEI CMM can do is to raise the floor, from poor to average—we’d be way ahead. we need to raise the ceiling.

what are great sw products? he made a list, commercially successful. what are the users passionate about? Unix, fortran, ... on the other side: cobol, os360, msdos, ... servicable but products that noone are really crazy about—what’s different? designed outside a product process[?] what we’ve got to do is to recruit great designers … systematic training programs … cherish, pay well, mold them into teams (DeMarco’s Peopleware book; go buy it)

preserving creativity: it’s important to give each member of the design team space, freedom to invent. OO makes the dominions clear, create freedom to do invention.

creativity magic: someone who violates all the rules, shows it off, everybody: way cool! wonderful when it happens. how do we make sure that this keeps on happening? managers need to encourage people, no matter how pressed the schedule is … spend 10% on wild catting, [3M, etc]—it’s going to happen anyway if you have an excited team—but you can encourage, credit it. so that people feel better about it. so that they can do it with a clear conscience, and open approval.

Q&A

code control, documentation tools, OOP —great improvements since he worked at IBM

architect worries about conceptiual integrity of the design—even more important with distributed teams

inertia in people resisting to putting in to formalization. any project growing faster than 40% will have a culture turmoil that will disturb the schedule. watch out for that rate of growth—give it a lot of attention. make the people feel that they OWN the control techniques