But after a week of watching a gut-wrenching roller-coaster ride on the New York stock market, and reading various gloom-and-doom predictions of bad economic times ahead, I thought it would be more appropriate to replace that talk with a presentation on “Death-March 3: Software Processes in the New Hard Times”:

If you click on either icon, you’ll download a 12.2-megabyte PDF file that actually contains both presentations. So you can look at either one of them, depending on whether you’re feeling optimistic or pessimistic. Enjoy … or don’t.  

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.

So far, this has elicited little more than a loud yawn (or perhaps it was a groan) from the blogosphere. Well, that’s understandable: who wants to try rewriting a 600-page book about a software methodology that predates UML and object-oriented stuff by 20-30 years? I feel your pain; it was pretty hard writing the first time around, too!

But how about spending a few minutes on a fairly minor task: adding hyperlinks to books, articles, interesting terms, and references to one or more chapters in the book? It’s relatively simply, doesn’t require you to be a rocket scientist, and may actually be helpful for future generations of students who are stumbling through this stuff. For whatever it’s worth, software companies are still hiring people with education or skills involving “Yourdon stuff”; with my various blog-searching and Google-keyword services, I see one or two job listings a week like this one, suggesting that there may be some economic value to learning what structured analysis is all about. And if you’ve got to learn about it, why not make it reasonably up to date?

As a small example, take a look at what I’ve done to Chapter 9 of my JESA book, which discusses data-flow diagrams in nauseating detail. I mention it because, to my eternal surprise, it has been the single most popular page on my website for well over a year. I couldn’t explain the phenomenon until I happened to notice that the Wikipedia article on dataflow diagrams contains a direct URL link to the aforementioned chapter. In any case, if you look closely at the first page or two of the chapter, and/or the “References” section at the end of the chapter, you’ll see that I’ve converted the original textual references to various textbooks and articles into hyperlinks to appropriate pages on the Web and/or pages within the Amazon bookstore, so that inquisitive readers can track down the material if they’re at all interested.

Again, this isn’t rocket science. But if you’re unfamiliar with the details of the MediaWiki quasi-HTML syntax, it may be a little intimidating at first. You’ll find a link on the left side of the page entitled “How To Use this Wiki,” and buried within that page is a URL that leads you to a “cheat sheet” that shows the syntax details for creating hyperlinks, as well as the syntax to formatting ordinary text into italicized and/or bold-face text, etc.

I haven’t finished fully annotated Chapter 9, but at least I’ve made a start; of particular interest is the reference to the excellent 1998 book, Complete Systems Analysis: The Workbook, the Textbook, the Answers, by James and Suzanne Robertson. That book wasn’t written until 9 years after my original Modern Structured Analysis book was written (though I had been acquainted with “the Robs,” as they were known, since the early 1980s), so obviously it wasn’t listed in the references of that original tome … nor was it in the JESA book that I first uploaded onto the Web in 2000. But it certainly deserves to be on the list, and now it is.

So, come on, folks! I’ll eventually get this updated and revised on my own, if need be, but it will be a long and slow process. More important, I’m sure I’ll overlook a bunch of stuff that other folks could add … or modify … or (shudder) delete. So, in what little spare time you might have available, track down the wiki and dig in! Future generations of students will thank you…

And indeed, it finished a couple weeks ago, and I should have made some kind of announcement at the time. But I was off in Japan, blogging away about the state of the japanese software industry and my experiences with customer service in Japanese hotels. And once I returned to New York, I was once again deluged with projects and deadlines; and so it was only a day or two ago that it occurred to me that I should let everyone know that the JESA wiki is now fully available.

Completely unrelated to all of this, I decided to peek at the statistics from OpenTracker this morning to see which portions of my website were getting the most traffic. To my surprise, I found that 8 of the 20 most-popular pages were individual chapters from the JESA wiki, and another 7 were various articles from this blog. So, one way or another, news of the JESA wiki is beginning to spread …

Anyone can visit read the current state of the material; but to edit and revise any of the material, you have to register on the wiki. It’s absolutely free, and I don’t use the email addresses for any purpose whatsoever; the registration mechanism is simply to minimize the amount of spam.

Meanwhile, if you’d just like to read the book without getting involved in the wiki community, it’s available as a PDF download by clicking here. You’ll be taken to a registration page that simply asks for your name, email address, job title, country, and (optional) comments. Again, it’s absolutely free, and I don’t use the email addresses for any purpose other than possibly notifying you if an update to the book is available.

But if you suffered through all 600+ pages of Modern Structured Analysis in college, and if you swore that you could have written a much better book than that idiot Yourdon guy … well, now’s your chance. Head on over to the JESA wiki, and make it a better book for the next generation of suffering students!

And if you really like structured analysis, you should visit the Just Enough Structured Analysis wiki on my web site. Otherwise, you should go back to whatever you were doing before you stumbled upon this blog posting.

This completes Part II of the book. There are still 9 chapters and 7 appendices to upload; as mentioned previously, it will probably take another couple of weeks to upload all of the material from the HTML-based manuscript, which is still on my website here.

In the meantime, you are welcome to start correcting, updating, revising, and improving the material that’s already on the wiki. I’ve been busy with about a dozen other projects recently, and have not yet had the chance to make very many of my own edits, aside from Amazon links for many of the books listed in the “References” section at the end of several chapters.

Of course, the wiki environment (we’re using MediaWiki for this initiative) provides the facility for adding comments and discussion; but if you’d prefer to make such comments outside the wiki environment, you’re welcome to add comments to this blog posting, or send email directly to me at “ed (at) yourdon (dot) com”.

As mentioned previously, will probably take another few weeks to upload all of the material from the HTML-based manuscript, which is still on my website here.

In the meantime, you are welcome to start correcting, updating, revising, and improving the material that’s already on the wiki. I’ve been busy with about a dozen other projects recently, and have not yet had the chance to make very many of my own edits, aside from Amazon links for many of the books listed in the “References” section at the end of several chapters.

Of course, the wiki environment (we’re using MediaWiki for this initiative) provides the facility for adding comments and discussion; but if you’d prefer to make such comments outside the wiki environment, you’re welcome to add comments to this blog posting, or send email directly to me at “ed (at) yourdon (dot) com”.

Steve’s talk was titled “The Ten Most Important Ideas in Software Engineering”; he emphasized that these are not new ideas, but ideas that are being “rediscovered” from other engineering disciplines, or simply ideas that have been discussed widely but not practiced widely. Here is Steve’s list:

1. Software development is performed by human beings. This notion was first popularized by Gerald Weinberg in 1971, with a book entitled The Psychology of Computer Programming (the silver anniversary edition of the book was republished in 1998). McConnell noted that estimating models like COCOMO-II demonstrate the significant cost/effort multipliers associated with having talented, experienced personnel on a project. He also suggests that we can draw three conclusions from this point: (a) the success of companies like Google, Yahoo, and Microsoft is not accidental, and is partially due to their emphasis on hiring talented people; (b) recruiting talented staff members is easily cost-justified; and (c) spending money on employee retention programs is cost-justified.
2. Incrementalism is essential. Steve distinguishes between “incremental” and “iterative” development; by “incrementalism,” he refers to the idea of developing a little bit at a time, in contrast to the big-bang software development approach.
3. Iteration is essential. This is a familiar concept, but Steve warned us to avoid accepting the all-or-nothing extremes of iteration. You don’t have to accept the “keep iterating forever” extreme, nor do you have to accept the “no iterations are allowed” waterfall approach.
4. The cost to increase a defect increases over time, throughout the development life cycle. This is a concept that has been widely accepted for the past 25 years, and McConnell says he has revalidated its truth with data as recent as 2004, including XP/agile projects. I was somewhat surprised by this, because a common argument from the XP/agile enthusiasts is that modern tools have made the old concept irrelevant — i.e., the XP/agile people argue that it doesn’t cost much to fix a requirements defect later in the development process, because modern IDE tools make it easy to redevelop software. McConnell obviously disagrees with this point, and I’ll have to look into it further before I make up my own mind.
5. There is an important kernel of truth in the waterfall model of development. McConnell suggests that the primary activities of software development are discovery (of what the requirements really are), invention (of a solution), and construction (i.e., implementation of that invented solution). And he argues that while these activities can overlap and take place somewhat concurrently, there is an intrinsically sequential nature to the activities.
6. The accuracy of estimates (about the schedule, effort, and cost) for a project increases over time throughout the development of a software system. There is a great deal of uncertainty in the initial estimates that we create at the beginning of a project. The “cone of uncertainty,” as McConnell calls it, does not narrow by itself, it must be actively managed. As a result, McConnell concludes that iteration must be iterative, project planning must be incremental, and that estimates aren’t meaningful unless they contain a description of their uncertainty.
7. The most powerful form of reuse is reuse of everything — not just code. We’ve long known that we should be reusing designs, plans, checklists, role, etc; and McConnell reminds us that we should be reusing processes for developing systems. Indeed, that’s what SEI-CMM level 3 is all about.
8. Risk management provides important insights into software development. McConnel notes that most projects spend more than 50% of their effort on unplanned work, and that the role of risk management is to reduce unplanned work.
9. Different kinds of software calls for different kinds of software development approaches. The “one size fits all” approach to software development methodologies is just plain silly
10. The Software Engineering Body of Knowledge (SWEBOK) is an important asset for software developers. SWEBOK has detailed information about 10 different areas of software development, including the familiar ones of analysis, design, construction, and testing. McConnell notes that it can be used for curriculum development, career development, certification, interviewing, and building a technical skills inventory.

Today’s presentation is from Joel Spolsky; if I get a chance this evening, I’ll post a blog entry summarizing his talk.

As mentioned previously, I’ll probably continue moving forward through the remaining chapters, at an average rate of a chapter a day. It will probably take another few weeks to upload all of the material from the HTML-based manuscript, which is still on my website here.

In the meantime, you are welcome to start correcting, updating, revising, and improving the material that’s already on the wiki. I’ve been busy with about a dozen other projects recently, and have not yet had the chance to start making my own edits — but I plan to do so as soon as I get a spare moment.

Of course, the wiki environment (we’re using MediaWiki for this initiative) provides the facility for adding comments and discussion; but if you’d prefer to make such comments outside the wiki environment, you’re welcome to add comments to this blog posting, or send email directly to me at “ed (at) yourdon (dot) com”.

As mentioned previously, I’ll probably continue moving forward through the remaining chapters, at an average rate of a chapter a day. It will probably take another few weeks to upload all of the material from the HTML-based manuscript, which is still on my website here.

In the meantime, you are welcome to start correcting, updating, revising, and improving the material that’s already on the wiki. I’ve been busy with about a dozen other projects recently, and have not yet had the chance to start making my own edits — but I plan to do so as soon as I get a spare moment.

Of course, the wiki environment (we’re using MediaWiki for this initiative) provides the facility for adding comments and discussion; but if you’d prefer to make such comments outside the wiki environment, you’re welcome to add comments to this blog posting, or send email directly to me at “ed (at) yourdon (dot) com”.

As mentioned previously, I’ll probably continue moving forward through the remaining chapters, at an average rate of a chapter a day. It will probably take another few weeks to upload all of the material from the HTML-based manuscript, which is still on my website here.

In the meantime, you are welcome to start correcting, updating, revising, and improving the material that’s already on the wiki. I’ve been busy with about a dozen other projects recently, and have not yet had the chance to start making my own edits — but I plan to do so as soon as I get a spare moment.

Of course, the wiki environment (we’re using MediaWiki for this initiative) provides the facility for adding comments and discussion; but if you’d prefer to make such comments outside the wiki environment, you’re welcome to add comments to this blog posting, or send email directly to me at “ed (at) yourdon (dot) com”.