I’m here in Rome this week, presenting a two-day seminar on  “Managing Death-March Projects” for Technology Transfer Institute. You should be there so you can hear whatever clever jokes may occur to me while I’m presenting my material, as well as the comments and questions from the other participants. But if you’re stuck in some other part of the world, or you couldn’t persuade your boss to send you to Rome, you can click here to download the (17MB) PDF version of the presentation, which has a whole  bunch of embedded links to other presentations, publications, books, articles, websites, etc.

Here’s the presentation:

These “patterns” are grimly familiar to anyone who has worked in project-related organizations; and unfortunately, they can be found in small companies as well as large ones. Fortunately, some of the patterns (“Rattle Yer Dags” and “Nanny,” for example) are good ones, and should be encouraged. Sadly, though, far too many of them (“Dead Fish”, “Project-Speak”) are not only depressingly familiar, but astonishingly destructive to productivity, quality, and the morale of the project team.

None of us will be able to memorize the titles of all 86 essays, especially when some of them (like “Rattle Yer Dags”) are somewhat cryptic. And in some organizations, it might be an act of political suicide to yell out, “Dead Fish!” in when the project manager convenes a status meeting for a project that everyone else knows was doomed from the very beginning. Maybe we need to use code words, like that old joke about the comedians who were so familiar with one another’s jokes, that they began referring to them by number:

“43!” the fledgling comedian yelled out to an audience of veteran comedians who had come to watch his first performance.

Nobody laughed. Nor did they laugh at 83, 29, or even the utterly hilarious 17 … and, I mean, who could not laugh at 17?

Perplexed, the young comedian asked his mentor, “Why didn’t they laugh when I said 43?”

“It’s not what the number is,” the veteran patiently explained to his young friend, “it’s how you say it …”

I really love this book, not the least because each pattern can be read and understood in a moment or two, since they take only 2-3 pages to explain. The real trick, I think, will be getting people to be brave enough to call them out when they are seen. Here’s a prediction: if you can encourage a few brave souls to shout “J’accuse!” whenever they see one of these patterns occurring in your organization, you’ll soon be able to remove all those Dilbert cartoons from the office bulletin board. If Adrenalin Junkies and Template Zombies gets the attention it deserves, Scott Adams may have to return to Corporate America and get an honest job as a project manager.

And maybe we won’t have any more Dead Fish …

To download the 20.5-megabyte PDF of the mind-map summary of this presentation, click here (or on the thumbnail icon above). The hyperlinks are preserved in the PDF file, so you’ll see clickable links that you can pursue to get more information on 18 recommended books, and 41 other references (articles, websites, blog articles, etc.) on key aspects of software engineering.

For the fans who follow this blog closely, you may recall seeing a similar mind-map for a “Top Ten” presentation that I did in Jacksonville, Florida a couple weeks ago. Here is a summary of the additions/changes I’ve added to that material for tomorrow’s presentation in Albany:

1. For the mind-map branch that refers to Google HR strategy, I’ve now found an interesting article in the Oct 21, 2007 issue of The New York Times, entitled “The Google Way: Give Engineers Room.”
2. As an additional reference on “peopleware” issues, I’ve included a relatively new book entitled Leading Geeks.
3. For the mind-map branch that refers to “evidence-based scheduling,” I’ve found a better reference: a very detailed Oct 26, 2007 blog posting entitled “Evidence-Based Scheduling” (duh!) by Joel Spolsky, of New York City’s Fog Creek Software. Highly recommended!

Let me know if you have any suggestions for improving the material …

I’m delighted to report that the article/report has now been published, in the September/October issue of the magazine, with the title “Celebrating Peopleware’s 20th Anniversary.” If you’re an IEEE member, you may have noticed the article, and/or received an e-mail notification of its publication; otherwise, you can find it here on the Internet. Alas, while my informal blog-version of the panel session is free, the official IEEE version will cost you $19. If it’s any consolation, neither my fellow co-panelists nor I receive a penny of this fee; and hopefully it will help keep a few engineers and programmers off the unemployment line a little while longer…

I had the great honor and pleasure of participating in a retrospective panel session on peopleware last week at the International Conference on Software Engineering (aka ICSE 2007) in Minneapolis, with some of the luminaries in the software field: Fred Brooks, Barry Boehm, Tom DeMarco, Tim Lister, and Linda Rising. The panel — celebrating the 20th anniversary of the publication of Peopleware — was conceived of, organized by, and moderated by Steve Fraser (not to be confused with this Steve Fraser, who won the 1984 Olympics in Greco-Roman wrestling); Steve, whose “day job” is that of Senior Staff at QUALCOMM’s Learning Center in San Diego, deserves a lot of credit for putting it all together, and keeping the panel from degenerating into pandemonium … and, well, Greco-Roman wrestling.

We began the session with brief introductions from everyone. Barry Boehm, whom we all know as the “father” of software engineering economics (and whose 1981 opus, Software Engineering Economics, should be read along with the newer vintage-2000 book, Software Cost Estimation with COCOMO-II) went first. Barry is the originator of the COCOMO software cost-estimating model, the “spiral” model of software development, and several other key ideas in software engineering; in addition to ongoing research work in these areas, he also teaches computer science (CS) and software engineering (SE) at the University of Southern California. He noted that undergraduate CS students are often taught that people are abstractions (e.g., they are taught to create systems model and diagrams where users are represented by stick-figures labeled U1, U2, … Un). And they are taught that project staffing is a “packaging” problem — if you need to accomplish X person-hours of work in Y calendar months, then you need to create a project with Z people (often known as “resources,” as another abstraction) in order to get the work done. Thus, Barry said, it’s a shock for such students to read Peopleware, and to be told that concepts like “jelling” and “teamicide” are realities.

Fred Brooks went next. Brooks is, of course, known for his work on the first big mainframe operating system, IBM’s OS/360; and he’s even better known for his landmark book, The Mythical Man-Month, as well as numerous technical papers such as “No Silver Bullet,” published in IEEE Software in April, 1987. But he told the audience that it’s been 20 years since he has taught, or focused seriously, on software engineering; most of his work now at the University of North Carolina is in the area of virtual reality. But he still insists that all of his students read Peopleware, and he predicts that the book will survive a long, long time. Why? For the same reason, he says, that the stories of Homer have survived for thousands of years: they are stories (and one of Peopleware’s great strengths, as several panelists emphasized, is that its important lessons are told in the form of stories) about people, and those stories are just as true today as they were a thousand years ago. Brooks says the he emphasizes four key points from the Peopleware book to his students:

• the importance of team jelling (not to be confused with the village of Jelling, in Denmark) and teamicide — a concept with which, having worked mostly on individual projects during their education, many CS students are entirely unfamiliar.
• the importance of “space” — i.e., giving programmers and software engineers a decent working environment, rather than a cramped cubicle with Muzak blaring from the ceiling — and the fact that the Peopleware book does such a good job of highlighting the importance.
• the emphasis on “people quality” — some people can write programs that are 10 times faster and smaller, and they can do so 10-20 times faster (see the January 1968 Communications of the ACM paper by Sackman, Erickson, and Grant, “Exploratory experimental studies comparing online and offline programming performance” for the first significant documented evidence of these differences); therefore, companies should try to hire such people, and should recruit, nurture, reward, and protect such people.
• the (negative) impact of moving a large software project, en masse, from one geographical location to another. A very few such projects survive a move, Brooks said, but only by starting over.

And I was on the panel, too, perhaps because of the rumor that Tom and Tim were initially going to title their Peopleware book All The Things Ed Yourdon Screwed Up When He Was Our Manager. But I think my sins (at least in that area) have been either forgiven or forgotten, and I did my best to avoid causing too much trouble on the panel. I told the audience that I had begun working in the software field — and wrote my first few technical books — during a period of youthful naivete when I thought that software development was a technical task, to be performed in a rational manner by mature adults. I gradually learned otherwise, though it was quite a shock to read Gerald Weinberg’s book, The Psychology of Computer Programming, in 1971 (republished in 1998 by Dorset House as a “silver anniversary edition“), and learn that software was at least partly a touchy-feely activity carried out by “people” (as opposed to cold, rational automatons). Sixteen years later, a new generation of software developers was equally shocked by the similar message in Peopleware, and I suggested to the audience that some of them listening today, in 2007, might be equally shocked by what they were hearing (and here’s a related question: has Scott Adams, creator of the “Dilbert” cartoon series and former IT professional at Pacific Bell Telephone, read Peopleware?).

But in fact, neither Weinberg’s 1971 message, nor DeMarco/Lister’s 1987 message, has become any less relevant in 2007: as Fred Brooks had already reminded us, people are the same as they were in the days of Homer. But one important thing has changed: the tools and mechanisms with which we can communicate, cooperate, and collaborate; when I started working in the software field in 1964, we didn’t even have email, let alone cell phones, instant messaging, teleconferencing, videoconferencing, wikis, blogs, and Twitter; we had to schedule long-distance calls with the switchboard operator, and we weren’t allowed to use the company photocopy machine for any purpose (such machines had their own “operator”). I was hoping that we might have a chance to discuss these communication mechanisms in more detail during the panel, partly because Tom DeMarco and I have an ongoing debate on the topic, but alas, it didn’t happen. I also made a self-serving reference to my Death March book, hoping that we’d have a chance to discuss the peopleware aspects of death-march projects during the panel discussion, but that didn’t happen either.

Linda Rising was the next to introduce herself; for those who haven’t heard of her, she is an expert in object-design metrics, and has done a great deal of work in the area of introducing software patterns and practices into organizations — including co-authoring the book Fearless Change with Mary Lynn Manns. She referred to Christopher Alexander’s 1977 book, A Pattern Language, and his 1979 book, The Timeless Way of Building – and asked how many in the audience had heard of his book; surprisingly (to me, at least), roughly 75% raised their hands. She suggested that that many of us in the software field had borrowed Alexander’s ideas about patterns, without even realizing that we had done so; she may or may not have been aware that my colleague, Larry Constantine, and I had borrowed an even earlier collection of Alexander’s ideas from a 1964 book called Notes on the Synthesis of Form, as the basis for the structured design concepts of coupling and cohesion. Anyway, Rising said she was interested in people-related patterns, too, which brought us back to the peopleware theme; Rising said that one of the things she like best from the Peopleware book was the story of the Danish legend of Holger Danske (you’ll have to click on the link to get the details).

Next came Tim Lister, who has been a professional colleague, and book-writing partner, of Tom’s since 1976 (Tim had come to work in my old consulting firm, YOURDON Inc., in the fall of 1975; Tom, whom I had first met in 1967, began working with our group in 1976). In addition to Peopleware, he and Tom have written several other books together, the most recent of which was Waltzing with Bears: managing risks on software projects. Tim suggested that 20 years might be a little too early to have a retrospective about the Peopleware book, but then went on to tell us how he and Tom conceived of the book and collected the material for its contents. What was originally just a few slides for the just-before-lunch session of a seminar they were teaching, they found that it unleashed a torrent of stories from real-world software managers about the good, the bad, and the ugly peopleware-related experiences in their projects. Looking forward, Tim said that he wanted to encourage the “agile” development community to continue exploring new ideas; and he wanted to encourage all of us to read a book by Rob Austin (who is not the same as this Rob Austin) and Lee Devin called Artful Making: what managers need to know about how artists work.

The last panel member to introduce himself was Tom DeMarco. Tom initially gained fame by writing one of the first, and by far the most readable, textbooks on structured analysis: Structured Systems Analysis and Specification. He has since written several other books, including the one that formed the basis for today’s panel session. As for Peopleware, Tom emphasized that it had been written as a team effort with Tim; and emphasizing something Tim had said earlier, Tom told the audience that owning half of something wonderful was far better than owning all of something that was merely “okay.” And while it was something he obviously felt strongly about, in terms of his own personal experience, he suggested that it was really a metaphor for something all of us should strive for, in the work we do; there’s a “multiplier” effect that we can achieve from the work that we do as part of a team, especially people you like and respect. But he said it was an unpredictable phenomenon, and referred obliquely to a coauthoring project in which the two authors never spoke to one another again after they finished the book (many of my former colleagues from YOURDON Inc. know who he was talking about, but out of friendship and respect for the two individuals, I’ll refrain from mentioning their names).

Repeating some of Tim’s themes, Tom said that the Peopleware book had let them become a “clearinghouse” for ideas about better ways of dealing with people in the IT profession. But he said that in some ways it was a failure — especially in the area of persuading IT managers to provide better working conditions for their programmers and software engineers. Even though phrases like “furniture police” have entered the common lexicon (you won’t find it in Wikipedia, but try Googling it and you’ll find plenty of entries, along with a couple for “police furniture“) along with evocative terms like teamicide (also not found in Wikipedia, but explained in detail in a post-Peopleware article by Tim and Tom called “Teamicide Revisited“), the reality is that all of the rational, quantitative arguments (including results from a massive 600-person coding “war game“) showing the positive correlation between decent office space and dramatically improved productivity and quality have had little or no effect on managers trying to squeeze the maximum number of people into the minimum number of cubic feet of office space.

So much for introductions: after everyone had said their introductory piece, moderator Steve Fraser opened the floor to questions. I did my best to scribble down the questions, and the responses from various panelists, but I can’t promise that I recorded everything completely accurately; in particular, I often couldn’t hear, spell, or understand the name and/or affiliation of some of the people who asked the questions; if any of you are reading this blog and recognize your pithy questions, please drop me an email note and fill in the details, so that I can correct the record.

The first question came from Michael Something-or-Other, who told us he was from Switzerland … though it wasn’t clear where in Switzerland. In any case, he told us that he had very much enjoyed the Peopleware book, but he wondered why it had taken so long for the agile development methodologies to become known and accepted. Here were the responses from the panel:

• Tom DeMarco responded quickly with the quip, “It’s all Barry’s fault!” He went on to suggest that we had all been brainwashed by Barry Boehm’s argument, first published in his Software Engineering Economics book, that the cost of repairing defects rises exponentially the later they’re found in the software life cycle (for a more recent exposition of this point, see the December 19, 2005 Dr. Dobb’s article by Yochi Slonim, “The Software Quality Lifecycle“). He said that as a result, the commandment “get the requirements right!” was drummed into the heads of a generation of software engineers. Tom turned towards Barry, smiled, wagged his finger, and said, “And I have never forgiven you!”
• Barry Boehm relieved the tension in the air by agreeing with Tom. He explained that, back in the 1970s, he had linked up with Win Royce at TRW, where the two of them found that the waterfall methodology worked pretty well. But he acknowledged that they were working in an application domain (aerospace systems, military systems), and in a time, when the end-user’s requirements were fairly well-defined; consequently, it made a great deal of sense to capture those requirements early, rather than discovering later on that a great deal of software had been built to implement the wrong requirements. But Boehm acknowledged that by the 1980s, things had begun to change drastically … and obviously this continues to be true today.
• I answered Michael’s question with a broader question of my own: Why has it taken our field so long to assimilate and accept any of the software engineering ideas that we all agree are useful, important, and generally successful? I suggested that if we were to poll an informal poll about not only agile methodologies, but also code inspections, identification of “error-prone” modules, etc., we would probably find that only 10% of the audience was actually using them. The audience stared back at me silently; I have no idea whether they understood, agreed with, or accepted what I was saying. I didn’t have time to expound upon the idea, but the question — why aren’t we doing things that we know are good ideas — is something I’ve blogged about here and here. Take a look, if you’re interested.
• Linda Rising suggested that the software industry grew to its present (enormous) size before it was ready — so we’ve always been searching for a model to emulate, whether it’s architecture or other engineering disciplines. (This is similar to comments I’ve often heard from other people, to the effect that our industry is “only” 50 years old, and that as such, it’s very young compared to other mature disciplines. Perhaps it took a few hundred years for engineers to figure out how to build bridges and houses without falling down…)

The next question came from Larry Bernstein, at Stevens Institute of Technology, who suggested that the main “driver” in our industry is fun. How can we organize our work — which consists of long hours of monotony, separated by moments of ecstasy — and ensure that our employers still make a profit?

• Linda Rising responded by telling us that she had recently given a talk on sex among primates, and how it all related to agile software development. If one can presume that sex is fun (at least for primates, and hopefully for human primates as well), maybe she’s got the answer. I don’t know anything about her talk, but you can check out this interview: “Linda Rising on Collaboration, Bonobos and the Brain.”
• Tom DeMarco suggested that “fun” equates to “play,” and said he had been influenced by Alan Kay’s distinction between “hard play” and “soft play.” Soft play, he suggested, is like watching American Idol, while hard play is learning to play the piano (A related article, “Hard Fun” . . . Squeak!” suggests that “Soft fun is watching people play baseball; hard fun is playing baseball. And, soft fun is watching someone play the violin and listening to a concert; and hard fun is you playing the violin.” As for Alan Kay’s thoughts on the subject, see “Amusing Ourselves to Life,” which requires a membership in ACM to download). In any case, Tom suggested that “hard play” is much more rewarding and fulfilling (and thus ultimately much more “fun”) than soft play, and that we should be focusing on that more, rather than sitting on our sofas and watching American Idol (which I’m proud to say I’ve never watched).
• Fred Brooks said that OS/360 was a once-in-a-lifetime experience, that he and his team felt that they really could change the world — much like the comments we used to hear from the original Macintosh team at Apple back in the mid-1980s. Part of the fun, he said, is being on a winning team. (And part of it may be the feeling, even if it’s only an illusion, that you and your fellow project team members really can change the world. Apple did. Google did. Marc Andreesen and his colleagues at Netscape did. The list goes on.)
• Barry Boehm suggested that we tend to overemphasize the contractual nature of many software development projects — especially when the user-developer relationship in an inhouse project gets transformed into a more form vendor-customer relationship for an externally developed system. We need to emphasize helping clients (or users) to win, too, he said, and look for win-win situations.
• I reminded the audience of the phenomenon we see in the open-source area: people often work at a “day job” that they hate, side-by-side with co-workers they despise, and taking orders from a manager they loathe. But then they go leave their day job, march into their office-at home (which is often equipped with more up-to-date computer facilities than what their employer gives them), and start having fun on an open-source project they love, with co-workers (who are located all over the world) they respect. So the business of having fun doesn’t have to be an all-or-nothing proposition; we’ve all got to find a way to pay the rent and put food on the table; but it doesn’t have to occupy us 16 hours a day.
• Fred Brooks suggested that only a small fraction of people on this planet have the luxury of working on something they consider fun. The fact that many of us in the software field can do so means that we’re blessed.

Mary Poppendieck then offered a comment, rather than a question, from the audience. She gave Fred Brooks a hard time by telling him that she had heard of his book in 1975, but didn’t like the term “man-month.” Brooks said that he was sorry if she was offended by the title, and said that even liberal people in the mid-70s, like John Gardner, were using that phrase. And besides, he said, the title was alliterative: “Mythical Person-Month” doesn’t roll off your tongue so easily.

Someone named Earl (not to be confused with “My Name Is Earl“) from some university, asked how he and his colleagues could take the experience of the panel, and transfer it to his computer science students?

• Linda Rising remarked that our whole educational model is flawed, and reminds her of the Monty Python Theory of Education, which involves slicing open the head of the presenter at the front of the room, scooping out knowledge and slicing open the heads of the participants and distributing the knowledge around in some fashion.. We should be moving towards an apprentice/mentor model, she said, much like we see in fields like architecture. Students should see software “masterpieces” from which they can learn.
• Tim Lister suggested that Earl was being way too hard on himself. Software, he said, is like paint: it’s a medium that you use differently depending on whether you plan to paint a wall or a Rembrandt. He argued vociferously (not that anyone on the panel disagreed with him), that the really big failure is not in the universities, but in IT organizations. Companies today invest zero in training, which is quite different from the situation he recalls when he first got into the field in the mid-1970s.
• Tom DeMarco pointed out that we might be able to use middle-schools as a guide: because of understaffing and overcrowded classrooms, industry people are working with teachers as partners. And the teachers are putting kids into teams, so they can help each other. The teachers will tinker with the teams, to increase the chances of jelling, and will tell them that everyone in the team gets the same grade.
• Barry Boehm said that his university is working on this problem at the Master’s degree level, and trying to figure out how to take it down to the freshman level in undergraduate curricula.
• Fred Brooks said, “People learn most concepts by induction from examples. Then, we’re so pleased at having discovered the generalization that we all teach by deduction from the generalization (just as I’m doing with this very statement). Thus we create an impedance mis-match between the learner and the teacher.” By contrast, what makes Peopleware popular is that it’s readable. And the reason it’s so readable is that it tells stories — vignettes like the tale of the furniture police. We need to do more of this in universities, and pass on the wisdom of the panelists and the Peopleware book by telling more stories in our computer science classes in our classes.

The next question came from Steve Easterbrook at the University of Toronto: why is there so little research on peopleware-related topics in academic circles, he asked. Someone in the audience immediately yelled “Tenure!”, which drew some chuckles and laughter from everyone else. Meanwhile, the panelists responded as follows:

• Linda Rising said that when she decided to go back to graduate school, she had trouble finding anyone on the faculty who was interested in such topics. The implication, of course, is that it becomes a self-perpetuating phenomenon.
• Tom DeMarco told us that he had submitted several papers to previous ICSE conferences on peopleware-related topics — which he described as “squishy” (not to be confused with squishy physics, or the Squishee soft drink on the Simpsons TV show, or Miss Squishy’s Flickr photos) — but that most of them had been rejected, except for a few that were finally accepted as “experience papers.”

Kevin Sullivan, from the University of Virginia (not to be confused with the Kevin Sullivan who gained fame as a professional wrestler, or several other Kevin Sullivans whose profile you can find on Wikipedia) , then asked why we are having such trouble attracting people in the computer science field, considering that many studies indicate that software offers the best jobs in the best geographical locations. The panelists responded:

• Tom DeMarco noted that when software was first identified as an “industry,” it had zero revenues; by 1985, as he recalled, its annual revenues were approximately $31 billion. Most of that money was spent on salaries, and many of the people who worked in the field were women, because it paid much better than most of the other jobs available to them. But starting about 5 years ago, he said, women started moving out of computer science and software engineering to medicine, law, and other professions (this phenomenon has been noted in an April 26, 2007 blog posting by Sean Voisen entitled “Women and the Decline of Computer Science,” and an April 17, 2007 New York Times article entitled “Computer Science Takes Steps to Bring Women to the Fold“). Tom suggests that this is happening because the workplace is now so unfriendly and uncomfortable — which includes, he says, the all-too-common experience of having to sit through one boring meeting after another, rather than doing interesting work.
• Fred Brooks agreed with the part about meetings: back in the 1960s, he said, meeting were small.
• Barry Boehm pointed out that one reason for the difficulty of attracting people into the computer field in Europe is that most of the large hardware companies in that part of the world have gone out of business. (But I think there are still plenty of software companies, but I didn’t feel like getting into a debate with Barry about this.)
• I suggested that another reason for the phenomenon is that high school graduates — at least in the U.S. — have been hearing about offshore outsourcing, and are concerned that all of the high-paying software jobs are moving to India; so if they major in computer science or software engineering, they won’t be able to get a job when they graduate. Whether or not this is actually true, it’s the perception that influences a university student’s choice of a major.

Next, David Jansen of Cal Poly (not to be confused with David Janssen, aka The Fugitive) told us that his students enjoy reading Peopleware, and that they use some of the material they’ve learned — stories about the furniture police — when going through interviews with prospective employers.

Next, Rob Deline, from Microsoft, told us that his company has been doing research on peopleware-related issues, and that it’s still going on. He noted that several people on the panel had written the textbooks for which they were best known while they were working in industry, after which they moved on to academia. Why, he asked, did this happen?

• Barry Boehm told us that his university does have an industry affiliate program … which implied that he understood Rob’s question to be slightly different than I had heard it: do industry people maintain any kind of relationship with academia?
• Linda Rising said that she gives talks at universities almost whenever asked to do so — and suggested that universities should be doing more of this (not just by inviting her more often, but by inviting all kinds of computer people from industry).

Tom Something-or-Other, from some university in England, suggested to the panel that we have a crisis related to getting more people interested in studying computer science — but that it starts at a much younger age, because students as young as 11-14 are getting “turned off” to math, science, and computing. How can we change this?

• Tom DeMarco suggested that we need to provide more educational materials to encourage “hard play” in the curriculum, in the sense that he described it earlier. I think another good example of this kind of “hard play” is the Logo programming language developed years ago by Seymour Papert and his colleagues. Tom also noted that Roger Pressman, whose software engineering book is probably the most widely-used text of its kind in universities, said that teachers need more support. I guess the implication is that it’s hard to prevent kids from getting turned off if you’re facing an overcrowded classroom, and can’t give individual attention to them.
• Barry Boehm suggested that both universities and industry could help the situation by sponsoring more “career days,” where parents come into the classroom to explain to the students what they do — which, of course, has long been going for years in other fields, with parents telling the kids what it’s like to be a soldier, a fireman, a policeman, or a doctor. (It’s interesting to note that this is not necessarily a completely altruistic notion: companies are also finding that it’s an excellent way of recruiting the best students, as described in a May 28, 2007 New York Times article entitled “In Fierce Competition, Google Finds Novel Ways to Feed Hiring Machine“)
• Fred Brooks noted that at his university, they also have laboratory presentations on virtual reality (which has been his area of specialization since the mid-70s) to middle-school children. He suggested that we need to think more about using simulations as a teaching mechanism.
• I suggested that all of this may be moot, because of the offshore outsourcing phenomenon mentioned earlier. Several CEOs of high-tech American firms have been heard to say that their firms will continue to prosper for the foreseeable future, even if they never hire another American ever again — because there is an ample supply of well-educated, lower-paid, hard-working graduates from China, India, and other parts of the world.

With our scheduled time drawing to a close, Steve Fraser asked the panelists to summarize their thoughts and positions on the peopleware issue. Here’s what everyone said:

• Barry Boehm told us that personnel is one of the top ten risks in software projects, so we should keep it in mind. And companies should devote more attention to retaining the good people that they have.
• I suggested that a lot of good ideas had come from the panelists, and from the audience, and that we should capture those ideas and distribute them more widely. That’s what this blog post is all about; and if anyone is aware of any other blogs that were written about this panel session, please let me know so that I can publish appropriate links to them.
• Tom DeMarco repeated the primary theme from the Peopleware book: the major problems of our industry are sociological, not technological.
• Fred Brooks told us to remember one word: people. It’s easy, he said, for us university people to forget that it’s people, not papers, that count. (That was a take-off on GE’s slogan that “Progress is our most important product.”)
• Tim Lister said that if we want to have fun, we should push decisions down in the hierarchy. And we should remember that the prime assets in our software organizations are people in the 25-30 age range; we should leave them alone, and buffer them from corporate bureaucracy.
• Linda Rising suggested that all of this — and perhaps the Peopleware book, too — seems so obvious; why do we even need to have a Peopleware book? But she said that her studies of cognitive psychology and primate sex taught her that, under stress, people fall apart and forget some essential things that they would otherwise practice quite competently. Patterns help us crawl out of a bad situation, and the stories in Peopleware have become a pattern.

And with that, the panel session came to a close, and everyone went their merry way. I thought it was a very productive session, and I hope we can do it again sometime. It may be premature to have a 21st-anniversary retrospective session, but maybe the 25th anniversary would be a good time to revisit these topics. I’ll leave that in the capable hands of Steve Fraser.