Skimming : Peopleware

Peopleware: Productive Projects and Teams (Second Edition)

MANAGING THE HUMAN RESOURCE

Somewhere Today, A Project is Failing

• For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure, (p.4)
• The major problems of our work are not so much technological as sociological in nature. (p.4)
• The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do. (p.5)

Make A Cheeseburger, Sell A Cheeseburger

• Development is inherently different from production. But managers of development and allied efforts often allow their thinking to be shaped by a management philosophy derived entirely from a production environment. (p.7)
• The "make a cheeseburger, sell a cheeseburger" mentality can be fatal in your development area. (p.7)
• Fostering an atmosphere that doesn't allow for error simply makes people defensive. ... The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously. (p.8)
• You may be able to kick people to make them active, but not to make them creative, inventive, and thoughtful. (p.9)
• The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work. (p.11)
• The more heroic the effort required, the more important it is that the team members learn to interact well and enjoy it (p.12)

Vienna Waits for You

• Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. (p.14)
• Your people are very aware of the one short life that each person is allotted. And they know too well that there has got to be something more important than the silly job they're working on. (p.15)
• Throughout the effort there will be more or less an hour of undertime for every hour of overtime. The trade-off might work to your advantage for the short term, but for the long term it will cancel out (p.15)
• Productivity has to be defined as benefit divided by cost. The benefit is observed dollar savings and revenue from the work performed, and cost is the total cost, including replacement of any workers used up by the effort. (p.18)
• A schedule that the project could actually meet was of no value to those Spanish Theory managers, because it didn't put the people under pressure. Better to have a hopelessly impossible schedule to extract more labor from the workers. (p.18)
• People under time pressure don't work better; they Just work faster. (p.18)

Quality—If Time Permits

• There may be many and varied causes of emotional reaction in one's personal life, but in the workplace, the major arouser of emotions is threatened self-esteem. (p.19)
• Any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you. (p.19)
• In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn't measure up to their own quality standards is almost always a mistake. (p.20)
• The point here is that the client's perceived needs for quality in the product are often not as great as those of the builder. There is a natural conflict. (p.21)
• Quality, far beyond that required by the end user, is a means to higher productivity. (p.22)

Parkinson's Law Revisited

• In a healthy work environment, the reasons that some people don't perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. (p.25)
• The most surprising part of the 1985 Jeffery-Lawrence study appeared at the very end, ... Projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all. (p.29)
• Organizational busy work tends to expand to fill the working day. (p.29)

Laetrile

• People who are desperate enough don't look very hard at the evidence. Similarly, lots of managers are "desperate enough," and their desperation makes them easy victims of a kind of technical laetrile that purports to improve productivity.(p.30)
• The manager's function is not to make people work, but to make it possible for people to work. (p.34)

THE OFFICE ENVIRONMENT

The Furniture Police

• But people work better in natural light. They feel better in windowed space and that feeling translates directly into higher quality of work. (p.40)
• Almost without exception, the workspaces given to intellect workers are noisy, interruptive, unprivate, and sterile. (p.40)
• Police-mentality planners design workplaces the way they would design prisons: optimized for containment at minimal cost. (p.40)

"You Never Get Anything Done Around Here between 9 and 5"

• Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment. (p.43)
• If you participate in or manage a team of people who need to use their brains during the work day, then the workplace environment is your business. (p.50)

Saving Money on Space

• ... minimum accommodation for the mix of people slated to occupy the new space would be the following:
  • 100 square feet of dedicated space per worker
  • 30 square feet of work surface per person
  • noise protection in the form of enclosed offices or six-foot high partitions
    (p.53)
• Noise is directly proportional to density, so halving the allotment of space per person can be expected to double the noise. (p.56)
• People are hiding out to get some work done. If this rings true to your organization, it's an indictment. Saving money on space may be costing you a fortune. (p.57)

Intermezzo : Productivity Measurement and Unidentified Flying Objects

• In order to make the concept deliver on its potential, management has to be perceptive and secure enough to cut itself out of the loop. That means the data on individuals is not passed up to management, and everybody in the organization knows it. (p.61)
• The individuals are inclined to do exactly the same things with the data that the manager would do. They will try to improve the things they do less well or try to specialize in the areas where theyalready excel. (p.61)

Brain Time Versus Body Time

• Thirty percent of the time, people are noise sensitive, and the rest of the time, they are noise generators. (p.62)
• Flow is a condition of deep, nearly meditative involvement. ... Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. (p.63)
• If you're a manager, you may be relatively unsympathetic to the frustrations of being in no-flow. After all, you do most of your own work in interrupt mode—that's management—but the people who work for you need to get into flow. (p.64)
• What matters is not the amount of time you're present, but the amount of time that you're -working at full potential. (p.65)
• Whenever the number of uninterrupted hours is a reasonably high proportion of total hours, up to approximately forty percent, then the environment is allowing people to get into flow when they need to. E-Factor = Uninterrupted Hours / Body-Present Hours (p.66)

The Telephone

• Do you often interrupt a discussion with co-workers or friends to answer a phone? Of course you do. You don't even consider not answering the phone. Yet what you're doing is a violation of the common rules of fairness, taking people out of order, just because they insist loudly (BBBRRRRHINNNNGGGGG!) on your attention. (p.71)
• The big difference between a phone call and an electronic mail message is that the phone call interrupts and the e-mail does not; (p.73)
• People must learn that it's okay sometimes not to answer their phones, and they must learn that their time—not just the quantity but its quality—is important. (p.74)

Bring Back The Door

• The most obvious symbol of success is the door. When there are sufficient doors, workers can control noise and mterruptability to suit their changing needs. The most obvious symbol of failure is the paging system. (p.75)
• What is more relevant is whether the workplace lets you work or inhibits you. Work-conducive office space is not a status symbol, it's a necessity. (p.77)
• The creative leap involves right-brain function. If the right brain, is busy listening to 1001 Strings on Muzak, the opportunity for a creative leap is lost. (p.79)
• The inconvenient fact of life is that the best workplace is not going to be infinitely replicable. Vital work-conducive space for one person is not exactly the same as that for someone else. (p.80)

Taking Umbrella Steps

• Christopher Alexander, architect and philosopher, is best  known for his observations on the design process. ... His philosophy of interior space is a compelling one. It helps you to understand what it is that has made you love certain spaces and never feel comfortable in others. (p.82)
• Alexander has very little patience with windowless space: "Rooms without a view are like prisons for the people who have to stay in them." (p.87)
• If you've ever had the opportunity to work in space that had an outdoor component, it's hard to imagine ever again limiting yourself to working entirely indoors. (p.89)
• At the entrance to the workplace should be some area that belongs to the whole group. It constitutes a kind of hearth for the group. (p.89)
• A common element that runs through all the patterns (both ours and Alexander's) is reliance upon non-replicable formulas. No two people have to have exactly the same workspace. (p.90)

THE RIGHT PEOPLE

The Hornblower Factor

• All of this means that getting the right people in the first place is all-important. (p.96)
• You're hiring on behalf of the whole corporate ladder above you. The perceived norm of these upper managers is working on you each time you consider making a new offer. That almost unsensed pressure is pushing toward the company average, encouraging you to hire people that look like, sound like, and think like everybody else. (p.97)
• In the corporation or other organization, entropy can be thought of as uniformity of attitude, appearance, and thought process. (p.99)
• SECOND THERMODYNAMIC LAW OF MANAGEMENT: Entropy is always increasing in the organization. (p.99)

Hiring A Juggler

• It would be ludicrous to think of hiring a juggler without first seeing him perform. (p.100)
• The aptitude tests we've seen are mostly left-brain oriented. That's because the typical things new hires do are performed largely in the left brain. The things they do later on in their career, however, are to a much greater degree right-brain activities. (p.103)
• So the hiring process needs to focus on at least some sociological and human communication traits. The best way we've discovered to do this is through the use of auditions for job candidates. (p.103)
• But it doesn't follow that aptitude tests are no good or that you ought not to be using them. You should use them, just not for hiring. (p.103)
• It soon became clear that the audition process served to accelerate the socialization process between a new hire and the existing staff members. (p.104)

Happy to be Here

• Employee turnover costs about twenty percent of all manpower expense. But that's only the visible cost of turnover. ... In companies with high turnover, people tend toward a destructively short-term viewpoint, because they know they just aren't going to be there very long. (p.106)
• But from the corporate perspective, late promotion is a sign of health. In companies with low turnover, promotion into the first-level management position comes only after as much as ten years with the company. (This has long been true of some of the strongest organizations within IBM, for example.) (p.108)
• ... a few reasons account for most departures:
  • a just-passing-through mentality: Co-workers engender no feelings of long-term involvement in the job.
  • a feeling of disposability: Management can only think of its workers as interchangeable parts (since turnover is so high, nobody is indispensable).
  • a sense that loyalty would be ludicrous: Who could be loyal to an organization that views its people as parts?
    (p. 108)
• But in the best organizations, the short term is not the only thing that matters. What matters more is being best. And that's a long-term concept. (p.111)
• A common feature of companies with the lowest turnover is widespread retraining. ... They realize that retraining helps to build the mentality of permanence that results in low turnover and a strong sense of community. They realize that it more than justifies its cost. (p.112)

The Self-Healing System

• When you automate a previously all-human system, it becomes entirely deterministic. The new system is capable of making only those responses planned explicitly by its builders. So the self-healing quality is lost. (p.113)
• The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology. (p.114)
• There is a big difference between Methodology and methodology. Small m methodology is a basic approach one takes to getting a job done. It doesn't reside in a fat book, but rather inside the heads of the people carrying out the work. ... Big M Methodology is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by the staff assigned to do the work. (p.115)
• Of course, if your people aren't smart enough to think their way through their work, the work will fail. No Methodology will help. (p.116)
• Convergence of method is a good thing. But Methodologies are not the only way to achieve convergence. (p.118)
• Better ways to achieve convergence of method are
  • Training: People do what they know how to do. If you give them all a common core of methods, they will tend to use those methods.
  • Tools: A few automated aids for modeling, design, implementation, and test will get you more convergence of method than all the statutes you can pass.
  • Peer Review: In organizations where there are active peer review mechanisms (quality circles, walkthroughs,inspections, technology fairs), there is a natural tendencytoward convergence.
    (p.118)
• It's only after this kind of gently guided convergence that you may think of publishing a standard. You can't really declare something a standard until it has already become a de facto standard. ... In that company's standards manual, it defines a standard as "a proven method for undertaking a repeated task." The manual goes on to explain that proven means "demonstrated widely and successfully within DuPont." (p.118)

GROWING PRODUCTIVE TEAMS

The Whole is Greater than The Sum of The Parts

• The reasons for this effect are not so complex: Teams by their very nature are formed around goals. ... Prior to a team's jelling, the individuals on the team might have had a diversity of goals. But as part of the jelling process, they have all bought on to the common goal. (p.123)
• There is very little true teamwork required in most of our work. But teams are still important, for they serve as a device to get everyone pulling in the same direction. The purpose of a team is not goal attainment but goal alignment. (p.126)
• The final sign of a jelled team is the obvious enjoyment that people take in their work. Jelled teams just feel healthy. The interactions are easy and confident and warm. (p.127)

The Black Team

• The Black Team was initially made up of people who had proved themselves to be slightly better at testing than their peers. They were slightly more motivated. (p.130)
• The team was a success. It succeeded as a test group, but more important for our purposes here, it succeeded as a social unit. People on the team got such a kick out of what they were doing that colleagues outside the team were positively jealous. (p.131)

Teamicide

• So instead of looking for ways to make team formation possible, we began to think of ways to make it impossible. (p.133)
• You can't protect yourself against your own people's incompetence. If your staff isn't up to the job at hand, you will fail. Of course, if the people are badly suited to the job, you should get new people. But once you've decided to go with a given group, your best tactic is to trust them. (p.133)
• People who feel untrusted have little inclination to bond together into a cooperative team. (p.135)
• Physical separation of people who are expected to interact closely doesn't make much sense anyway. Neighboring workers are a source of noise and disruption. When they're all on the same team, they tend to go into quiet mode at the same time, so there is less interruption of flow. (p.136)
• No one can be part of multiple jelled teams. The tight interactions of the jelled team are exclusive. Enough fragmentation and teams just won't jell. The saddest thing is we allow far more fragmentation than is really necessary. (p.137)
• Co-workers who are developing a shoddy product don't even want to look each other in the eye, There is no joint sense of accomplishment in store for them. They know that there will be a general sense of relief when they can stop doing what they're doing. At the end of the project, they'll make every effort to separate themselves from other members of the group, and get on to better things. (p.137)
• But there are certainly cases where a tight but not impossible deadline can constitute an enjoyable challenge to the team. What's never going to help, however, is a phony deadline. (p.138)
• The team phenomenon, as we've described it, is something that happens only at the bottom of the hierarchy. ... When managers are bonded into teams, it's only because they serve dual roles: manager on the one hand and group member on the other. (p.139)

A Spaghetti Dinner

• The common thread is that good managers provide frequent easy opportunities for the team to succeed together. (p.141)
• The best boss is the one who can manage this over and over again without the team members knowing they've been "managed." (p.142)

Open Kimono

• This Open Kimono attitude is the exact opposite of defensive management. You take no steps to defend yourself from the people you've put into positions of trust. And all the people under you are in positions of trust. A person you can't trust with any autonomy is of no use to you. (p.144)
• They're not just getting a job done. They're making sure that the trust that's been placed in them is rewarded. It is this kind of Open Kimono management that gives teams their best chance to form. (p.145)
• If you've got decent people under you, there is probably nothing you can do to improve their chances of success more dramatically than to get yourself out of their hair occasionally. (p.146)
• What seemed to matter was the chance for people to work with those they wanted to work with. (p.148)
• Between master craftsman and apprentice there is a bond of natural authority—the master knows how to do the work and the apprentice does not. Submitting to this kind of authority demeans no one, it doesn't remove incentive, it doesn't make it impossible to knit with fellow workers.  (p.148)

Chemistry For Team Formation

• In organizations with the best chemistry, managers devote their energy to building and maintaining healthy chemistry. Departments and divisions that glow with health do so because their managers make it happen. (p.150)
• The opposite attitude, of "only perfect is close enough for us," gives the team a real chance. This cult of quality is the strongest catalyst for team formation. It binds the team together because it sets them apart from the rest of the world. The rest of the world, remember, doesn't give a hoot for quality. (p.151)
• When team members develop a cult of quality, they always turn out something that's better than what their market is asking for. They can do this, but only when protected from short-term economics. (p.152)
• The chemistry-building manager takes pains to divide the work into pieces and makes sure that each piece has some substantive demonstration of its own completion. ... Each new version is an opportunity for closure. Team members get warmed up as the moment approaches, they sprint near the very  end. (p.152)
• A jelled team does have the effect of making people more productive and goal-directed. And you do give up some control, or at least the illusion of control, when it jells. The team begins to feel elite in some way or other, with all members of the team sharing in the sense of eliteness.  (p.154)
• On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. (p.155)

ITS SUPPOSED TO BE FUN TO WORK HERE

Chaos And Order

• One caveat about pilot projects: Don't experiment with more than one aspect of development technology on any given project. (p.161)
• From four years of running our Coding War Games, we have learned that the sometimes raucous, competitive, no-lose experience can be a delightful source of constructive disorder. (p.162)
• There can be no question that good sense and order are desirable components of our work day. There's also a place for adventure, silliness, and small amounts of constructive disorder. (p.166)

Free Electrons

• It's hardly hot news these days that lots of our peers are working as cottage industry entrepreneurs. They contract their time by the day or week for programming or design work or sometimes management. (p.167)
• Organizations are under increasing pressure to offer attractive in-house alternatives to their best people lest they become part of the cottage industry phenomenon. One such alternative is a position with loosely stated responsibilities so that the individual has a strong say in defining the work. (p.168)
• Our colleague Steve McMenamin characterizes these workers as "free electrons," since they have a strong role in choosing their own orbits. (p.168)
• The reason there are so many gurus and Fellows and intrapreneurs and internal consultants in healthy modern companies is quite simply that companies profit from them. (p.168)
• The mark of the best manager is an ability to single out the few key spirits who have the proper mix of perspective and maturity and then turn them loose. (p.170)

Holgar Dansk

• The key to success in fostering the kind of change we're advocating is that you not try to wrestle the bull. You're certainly not strong enough for that. (p.172)
• There may be a sleeping giant inside your own organization, ready to awaken when it is in danger. It is in danger if there is too much entropy, too little common sense. The giant is the body of your co-workers and subordinates, rational men and women whose patience is nearly exhausted. (p.173)

SON OF PEOPLEWARE

Teamicide Revisited

• These motivational accessories, as they are called (including slogan coffee mugs, plaques, pins, key chains, and awards), are a triumph of form over substance. (p.178)
• Extended overtime is a productivity-reduction technique, anyway. The extra hours are almost always more than offset by the negative side effects. (p.180)

Competition

• At the extreme, at least, competition is certain to inhibit team jell. (p.181)
• What is the long-term effect of heightened competition among people who need to work together? One of the first victims is the easy, effective peer-coaching that is ubiquitous in healthy teams. (p.182)
• When you observe a well-knit team in action, you'll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher. Their roles tend to switch back and forth over time ... (p.182)
• Our point here is somewhat more limited: Any action that rewards team members differentially is likely to foster competition. Managers need to take steps to decrease or counteract this effect. (p.184)

Process Improvement Programs

• Standards are good. ... but it's worth pointing out that the great triumph of standards in the modern world is almost entirely the success of standard interfaces. ... how it interfaces with its corresponding parts—but nothing about the process for building that product. (p.187)
• Competent people are involved in process improvement all the time: They take pride in progress and growth, and these can only come from getting more proficient at what they do. This kind of low-level process refinement is the basic hygiene of knowledge work, but formal process improvement moves responsibility up from the individual to the organization. (p.188)
• Organizations that build products with the most value to their customers win. Those that build products that make the world yawn lose, even though they build them very, very efficiently. (p.189)
• All the projects that carry real benefit carry real risks along with them. It is the project that has some novelty, some innovation or invention, that might grab the customer's imagination and wallet. (p.189)
• One of the strongest justifications for the CMM is that it will raise quality and productivity while decreasing risk .... Organizations become more and more averse to risk as they "mature." An organization under the gun to demonstrate increased CMM level is not going to go looking for real challenge.  (p.190)
• Raising the bar means that risk will increase. The more proficient you are, the more risk you take on. You'd be crazy not to (p.191)
• As we make real progress in process improvement, we need more talented and more experienced people to do the work (p.191)
• You need as much proficiency as you can possibly build into your organization. You need that in order to take on ever-more risky projects. The Key Process Areas, as identified by the SEI, will be useful to you in building proficiency; they define sets of skills that ought to be on any good software manager's wish list. Focus on the KPA skills, but do whatever you can to turn off the institutional score-keeping. (p.192)

Making Change Possible

• "You don't get it. I'm sorry, but people really, truly hate change. That's the problem: They're not rejecting a particular change on its merits; they're rejecting any change. And that's because people hate change." (p.194)
• Johnson asserts that the Believers but Questioners are the only meaningful potential allies of any change. The two extremes, Blindly Loyal and Militantly Opposed, are the real enemies. (p.197)
• MANTRA: The fundamental response to change is not logical, but emotional. (p.197)
• Instead, we need to celebrate the old as a way to help change happen. (p.198)
• When you try to institute change, the first thing you hit is Chaos. ... You are suffering from the dip in the learning curve, and the assessment that the change is the problem may well be right, at least for the moment. You are worse off, for now. This is part of the reason why response to change is so emotional. (p.199)
• An interesting characteristic of human emotion is that the more painful the Chaos, the greater the perceived value of the New Status Quo—if you can get there. (p.200)
• Change won't even get started unless people feel safe—and people feel safe when they know they will not be demeaned or degraded for proposing a change, or trying to get through one. (p.200)
• Paradoxically, change only has a chance of succeeding if failure—at least a little bit of failure—is also okay. (p.201)

Human Capital

• An investment, on the other hand, is use of an asset to purchase another asset. The value has not been used up, but only converted from one form to another. When you treat an expenditure as an investment instead of as an expense, you are said to be capitalizing the expenditure. (p.203)
• Companies of knowledge-workers have to realize that it is their investment in human capital that matters most. (p.208)

Organizational Learning

• Experience gets turned into learning when an organization alters itself to take account of what experience has shown. This alteration takes two forms, which are different enough to talk about separately:
  • The organization instills new skills and approaches in its people.
  • The organization redesigns itself to operate in some different manner.
    (p.210)
• Learning is limited by an organization's ability to keep its people. (p.210)
• That means the most natural learning center for most organizations is at the level of that much-maligned institution, middle management. This squares exactly with our own observation that successful learning organizations are always characterized by strong middle management. (p.212)
• In order for a vital learning center to form, middle managers must communicate with each other and learn to work together in effective harmony. This is an extremely rare phenomenon. (p.212)

The Ultimate of Management Sins is ...

• The ultimate management sin is wasting people's time. (p.215)
• Organizations have need of ceremony. It's perfectly reasonable to call a meeting with a purpose that is strictly ceremonial,  particularly at project milestones, when new people come on board, or for celebrating good work by the group. Such meetings do not waste anyone's time. ... Ceremonial meetings that only celebrate the bossness of the boss, however, are a waste. (p.217)
• Fragmented time is almost certain to be teamicidal, but it also has another insidious effect: It is guaranteed to waste the individual's time. (p.220)

The Making of Community

• Community doesn't just happen on the job. It has to be made. The people who make it are the unsung heroes of our work experience. (p.223)
• An organization that succeeds in building a satisfying community tends to keep its people. When the sense of community is strong enough, no one wants to leave. (p.224)
• Like any work of art, your success at fostering community is going to require substantial talent, courage, and creativity. It will also need an enormous investment of time. The work will not be completed by you alone; at best, you will be the catalyst. (p.225)

Skimming : The Mythical Man-Month

The Mythical Man-Month

The Tar Pit

• Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program. (p.8)
• The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion. Already colleagues and competitors are in hot pursuit of new and better ideas. (p.9)

The Mythical Man Month

• our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. (p.14)
• All programmers are optimists. (p.14)
• Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. (p.16)
• Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (p.16)
• In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. (p.17)
• For some years I have been successfully using the following rule of thumb for scheduling a software task:
• l/3 planning
• 1/6 coding
• 1/4 component test and early system test
• 1/4 system test, all components in hand. (p.20)
• Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish derived estimates. (p.21)
• Adding manpower to a late software project makes it later. (p.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. (p.25)

The Surgical Team

• Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! (p.30)
• The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled? (p.31)
• ... but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity. (p.32)
• The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation. (p.32)
• The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. (p.32)
• The administrator. The surgeon is boss, and he must have the last word on personnel, raises, space, and so on, but he must spend almost none of his time on these matters. (p.33)
• The editor. The surgeon is responsible for generating the documentation—for maximum clarity he must write it. This is true of both external and internal descriptions. The editor, however, takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several versions, and oversees the mechanics of production. (p.33)
• The program clerk. He is responsible for maintaining all the technical records of the team in a programming-product library. (p.33)
• The toolsmith. ... He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team. (p.34)
• The tester. The surgeon will need a bank of suitable test cases for testing pieces of his work as he writes it, and then for testing the whole thing. (p.34)
• The language lawyer. The language lawyer can find a neat and efficient way to use the language to do difficult, obscure, or tricky things. (p.34)
• ... lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo. Yet the specialization of function of the remainder of the team is the key to its efficiency, (p.35)

Aristocracy, Democracy, and System Design

• The purpose of a programming system is to make a computer easy to use. (p.43)
• For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. ... Simplicity and straightforwardness proceed from conceptual integrity. (p.44)
• Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. (p.44)
• The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects. (p.44)
• Are not the architects a new aristocracy, an intellectual elite, set up to tell the poor dumb implementers what to do? (p.46)
• Good features and ideas that do not integrate with a system's basic concepts are best left out. ... If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology. (p.46)
• Indeed, the cost-performance ratio of the product will depend most heavily on the implementer, just as ease of use depends most heavily on the architect. (p.46)

The Second-System Effect

• An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint. (p.55)
• Sooner or later the first system is finished, and the architect, with firm, confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs. (p.55)
• How does the architect avoid the second-system effect? Well, obviously he can't skip his second system. But he can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.  (p.58)

Passing the Word

• The manual is the external specification of the product. It describes and prescribes every detail of what the user sees. As such, it is the chief product of the architect. (p.62)
• The manual must not only describe everything the user does see, including all interfaces; it must also refrain from describing what the user does not see. That is the implementer's business, and there his design freedom must be unconstrained. (p.62)
• As noted, formal definitions are precise. They tend to be complete; gaps show more conspicuously, so they are filled sooner. What they lack is comprehensibility. (p.63)
• For these reasons, I think we will see future specifications to consist of both a formal definition and a prose definition. (p.64)
• An ancient adage warns, "Never go to sea with two chronometers; take one or three." The same thing clearly applies to prose and formal definitions. If one has both, one must be the standard, and the other must be a derivative description, clearly labeled as such. (p.64)
• Needless to say, meetings are necessary. ... Anyone can propose problems or changes, but proposals are usually distributed in writing before the meeting. (p.66)
• In most computer projects there comes a day when it is discovered that the machine and the manual don't agree. When the confrontation follows, the manual usually loses, for it can be changed far more quickly and cheaply than the machine. Not so, however, when there are multiple implementations. Then the delays and costs associated with fixing the errant machine can be overmatched by delays and costs in revising the machines that followed the manual faithfully.  (p.68)
• It is essential, however, to encourage the puzzled implementer to telephone the responsible architect and ask his question, rather than to guess and proceed. ... One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer.  (p.69)
• Every development organization needs such an independent technical auditing group to keep it honest. (p.69)

Why Did the Tower of Babel Fail?

• According to the Genesis account, the tower of Babel was man's second major engineering undertaking, after Noah's ark. Babel was the first engineering fiasco. (p.74)
• If there are n workers on a project, there are (n2-n)/2 interfaces across which there may be communication, and there are potentially almost 2" teams within which coordination must occur. The purpose of organization is to reduce the amount of communication and coordination necessary; hence organization is a radical attack
• on the communication problems treated above. (p.78)
• Let us consider a tree-like programming organization, and examine the essentials which any subtree must have in order to be effective. They are:
1. a mission
2. a producer
3. a technical director or architect
4. a schedule
5. a division of labor
6. interface definitions among the parts
   (p.79)

• What is the role of the producer? He assembles the team, divides the work, and establishes the schedule. He acquires and keeps on acquiring the necessary resources. This means that a major part of his role is communication outside the team, upwards and sideways. (p.79)
• How about the technical director? He conceives of the design to be built, identifies its subparts, specifies how it will look from outside, and sketches its internal structure. He provides unity and conceptual integrity to the whole design; thus he serves as a limit on system complexity.  (p.80)

Calling the Shot

• First, one must say that one does not estimate the entire task by estimating the coding portion only and then applying the ratios. The coding is only one-sixth or so of the problem, and errors in its estimate or in the ratios could lead to ridiculous'results. (p.88)
• effort goes as a power of size even when no communication is involved except that of a man with his memories. (p.88)
• Productivity seems constant in tenns of elementary statements, a conclusion that is reasonable in terms of the thought a statement requires and the errors it may include."
• Programming productivity may be increased as much as five times when a suitable high-level language is used. (p.94)

Ten Pounds in a Five-Pound Sack

• Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager. (p.100)
• Obviously, more function means more space, speed being held constant. So the first area of craftsmanship is in trading function for size. (p.101)
• The second area of craftsmanship is space-time trade-offs. For a given function, the more space, the faster. This is true over an amazingly large range. It is this fact that makes it feasible to set space budgets. (p.101)
• The programmer at wit's end for lack of space can often do best by disentangling himself from his code, rearing back, and contemplating his data. Representation is the essence of programming. (p.103)

The Documentary Hypothesis

• The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones (p.111)
• the documents will communicate the decisions to others. The manager will be continually amazed that policies he took for common knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making, and his documents will immensely lighten this load. (p.111)
• The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable. Such a plan consists of documents on what, when, how much, where, and who.  (p.112)

Plan to Throw One Away

• In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. (p.116)
• The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. (p.116)
• The first step is to accept the fact of change as a way of life, rather than an untoward and annoying exception. (p.117)
• 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. (p.118)
• He observes that 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. (p.118)
• The barriers are sociological, and they must be fought with constant vigilance. First, managers themselves often think of senior people as "too valuable" to use for actual programming. (p.119)
• The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back. (p.122)
• They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system. (p.122)

Sharp Tools

• General-purpose tools are not enough, however. Both specialized needs and personal preferences dictate the need for specialized tools as well; so in discussing programming teams I have postulated one toolmaker per team. (p.128)
• When a man had his component ready for integration into a larger piece, he passed a copy over to the manager of that larger system, who put this copy into a system integration sublibrary. Now the original programmer could not change it, except by permission of the integration manager. (p.133)
• The chief reasons for using a high-level language are productivity and debugging speed. (p.135)
• The debugging improvement comes from the fact that there are fewer bugs, and they are easier to find. There are fewer because one avoids an entire level of exposure to error, a level on which one makes not only syntactic errors but semantic ones, such as misusing registers. (p.135)
• What high-level language should one use for system programming? The only reasonable candidate today is PL/I. (p.135)

The Whole and the Parts

• conceptual integrity of the product not only makes it easier to use, it also makes it easier to build and less subject to bugs. (p.142)
• Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of cosmetic relief. Top-down design reduces the temptation. I am persuaded that top-down design is the most important new programming formalization of the decade. (p.144)
• Common sense, if not common practice, dictates that one should begin system debugging only after the pieces seem to work. (p.147)
• the use of clean, debugged components saves much more time in system testing than that spent on scaffolding and thorough component test. (p.148)
• By scaffolding I mean all programs and data built for debugging purposes but never intended to be in the final product. It is not unreasonable for there to be half as much code in scaffolding as there is in product. (p.148)
• Note that one must have thorough test cases, testing the partial systems after each new piece is added. And the old ones, run successfully on the last partial sum, must be rerun on the new one to test for system regression. (p.150)

Hatching a Catastrophe

• Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will. (p.154)
• Rarely will a man lie about milestone progress, if the milestone is so sharp that he can't deceive himself. But if the milestone is fuzzy, the boss often understands a different report from that which the man gives. (p.155)
• There is no substitute for a PERT chart or a critical-path schedule. Such a network shows who waits for what. It shows who is on the critical path, where any slip moves the end date. It also shows how much an activity can slip before it moves into the critical path. (p.156)
• The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status. (p.157)
• The investment of a modest amount of skilled effort in a Plans and Controls function is very rewarding. ... For the Plans and Controls group is the watchdog who renders the imperceptible delays visible and who points up the critical elements. It is the early warning system against losing a year, one day at a time. (p.160)

The Other Face

• Thomas J. Watson, Sr. told the story of his first experience as a cash register salesman in upstate New York. Charged with enthusiasm, he sallied out with his wagon loaded with cash registers. He worked his territory diligently but without selling a one. Downcast, he reported to his boss. The sales manager listened a while, then said, "Help me load some registers into the wagon, harness the horse, and let's go again." They did, and the two called on customer after customer, with the older man showing how to sell cash registers. All evidence indicates that the lesson took. (p.164)
• To use a program. Every user needs a prose description of the program. Most documentation fails in giving too little overview. The trees are described, the bark and leaves are commented, but there is no map of the forest. (p.165)
• To believe a program. The description of how it is used must be supplemented with some description of how one knows it is working. This means test cases. (p.165)
• The solution, I think, is to merge the files, to incorporate the documentation in the source program. This is at once a powerful incentive toward proper maintenance, and an insurance that the documentation will always be handy to the program user. Such programs are called self-documenting. (p.169)
• The first notion is to use the parts of the program that have to be there anyway, for programming language reasons, to carry as much of the documentation as possible. So labels, declaration statements, and symbolic names are all harnessed to the task of conveying as much meaning as possible to the reader. (p.172)

No Silver Bullet - Essence and Accident in Software Engineering

• Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any—no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware.  (p.181)
• Following Aristotle, I divide them into essence—the difficulties inherent in the nature of the software—and accidents—those difficulties that today attend its production but that are not inherent. (p.182)
• The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence.  (p.183)
• Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. ... These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God. (p.184)
• What does a high-level language accomplish? It frees a program from much of its accidental complexity. (p.186)
• The concept of the abstract data type is that an object's type should be defined by a name, a set of proper values, and a set of proper operations, rather than its storage structure, which should be hidden. (p.189)
•  The hard thing about building software is deciding what to say, not saying it. (p.191)
• For almost 40 years, people have been anticipating and writing about "automatic programming," the generation of a program for solving a problem from a statement of the problem specifications. (p.193)
• The VLSI analogy is fundamentally misleading—a chip design is a layered two-dimensional object whose geometry reflects its essence. A software system is not. (p.195)
• Language-specific smart editors are developments not yet widely used in practice, but the most they promise is freedom from syntactic errors and simple semantic errors. (p.196)
• Buy versus build. The most radical possible solution for constructing software is not to construct it at all. (p.197)
• The cost of software has always been development cost, not replication cost. (p.198)
• During the 1950s and 1960s, study after study showed that users would not use off-the-shelf packages for payroll, inventory control, accounts receivable, etc. ... During the 1980s, we find such packages in high demand and widespread use. What has changed? (p.198)
• The buyer of a $2-million machine in 1960 felt that he could afford $250,000 more for a customized payroll program, Buyers of $50,000 office machines today cannot conceivably afford customized payroll programs; so they adapt their payroll procedures to the packages available. (p.198)
• Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. (p.199)
• Therefore one of the most promising of the current technological efforts, and one which attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements. (p.200)
• The secret is that it is grown, not built. So it must be with our software systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development (p.201)
• I find that teams can grow much more complex entities in four months than they can build. (p.201)
• The central question of how to improve the software art centers, as it always has, on people. ... Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge. (p.202)
• My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. (p.203)
• How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:
• Systematically identify top designers as early as possible. The best are often not the most experienced.
• Assign a career mentor to be responsible for the development of the prospect, and keep a careful career file.
• Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo design and technical leadership assignments.
• Provide opportunities for growing designers to interact with and stimulate each other.
  (p.203)

The Mythical Man-Month after 20 Years

• Human history is a drama in which the stories stay the same, the scripts of those stories change slowly with evolving cultures, and the stage settings change all the time. (p.255)
• A clean, elegant programming product must present to each of its users a coherent mental model of the application, of strategies for doing the application, and of the user-interface tactics to be used in specifying actions and parameters. The conceptual integrity of the product, as perceived by the user, is the most important factor in ease of use. (p.255)
• Any product that is sufficiently big or urgent to require the effort of many minds thus encounters a peculiar difficulty: the result must be conceptually coherent to the single mind of the user and at the same time designed by many minds. (p.256)
• Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity. (p.257)
• Paradoxically, it is much more difficult to design a general purpose tool than it is to design a special-purpose tool, precisely because one has to assign weights to the differing needs of the diverse users. (p.258)
• The larger and more amorphous the user set, the more necessary it is to define it explicitly if one is to achieve conceptual integrity.
• Who they are
• What they need
• What they think they need
• What they want
  (p.258)
• The WIMP is a superb example of a user interface that has conceptual integrity, achieved by the adoption of a familiar mental model, the desktop metaphor, and its careful consistent extension to exploit a computer graphics implementation.  (p.260)
• "Plan to throw one away; you will, anyhow." This I now perceive to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the "Build one to throw away" concept is that it implicitly assumes the classical sequential or waterfall model of software construction. (p.265)
• Rather less familiar, but very important, is Parnas's concept of designing a software product as a family of related products. He urges the designer to anticipate both lateral extensions and succeeding versions of a product, and to define their function or platform differences so as to construct a family tree of related products. The trick in the design of such a tree is to put near its root those design decisions that are less likely to change. (p.269)
• Parnas was right, and I was wrong. I am now convinced that information hiding, today often embodied in object-oriented programming, is the only way of raising the level of software design. (p.272)
• that creativity comes from individuals and not from structures or processes, then a central question facing the software manager is how to design structure and process so as to enhance, rather than inhibit, creativity and initiative. (p.277)
• The classical industry tended to be dominated by large firms with established management styles and work cultures. The shrink-wrapped industry, on the other hand, began as hundreds of start-ups, freewheeling and fiercely focused on getting the job done rather than on process. (p.284)
• An especially promising trend is the use of mass-market packages as the platforms on which richer and more customized products are built. (p.285)
• Because the build-on-package phenomenon does not today affect the average MIS programmer, it is not yet very visible to the software engineering discipline. Nevertheless, it will grow rapidly, because it does attack the essence of fashioning conceptual constructs. (p.285)