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.  

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 …

If you’d like to download a 15.9-megabyte PDF of the one-page mind-map for the presentation, click here. And if you’d like to see the Google Docs version of the presentation, click here. Because Google Docs presentations are sharable, there’s an opportunity for you to revise, enhance, correct, and generally improve the material. In order to do that, you’ll need to be added to the list of “collaborators” for the document; send me an email at ed-at-yourdon-to-com, and I’ll add you to the list.

In any case, it appears that a similar software problem has appeared in a newer, state-of-the-art military plane: an article in today’s Slashdot, entitled “Software Bug Halts F-22 Flight,” says:

“”The new US stealth fighter, the F-22 Raptor, was deployed for the first time to Asia earlier this month. On Feb. 11, twelve Raptors flying from Hawaii to Japan were forced to turn back when a software glitch crashed all of the F-22s’ on-board computers as they crossed the international date line. The delay in arrival in Japan was previously reported, with rumors of problems with the software. CNN television, however, this morning reported that every fighter completely lost all navigation and communications when they crossed the international date line. They reportedly had to turn around and follow their tankers by visual contact back to Hawaii. According to the CNN story, if they had not been with their tankers, or the weather had been bad, this would have been serious. CNN has not put up anything on their website yet.”

All of which should remind us to be very humble: we have much better technology than we did in 1980, but we’re building much larger, more complex systems. And even though you would think that programmers would write their code to behave appropriately when a plane crosses the equator or the international date line, and even though you would think the QA people would remember to include this as part of their testing regimen, there are still some very unhappy pilots out there.

But if you do work in the software field, you might want to give the question some serious thought. I was asked to do so yesterday, as part of a panel session on the final day of the JaSST conference that I attended here in Tokyo. Two other panelists and I were given a short ten minutes to present our ideas, before the audience was invited to express their opinions and ask some questions. My three proposals for improving the overall state of software quality focused on these areas: politics, collaboration, and negotiating tradeoffs.

Politics might seem a strange thing to talk about, in the context of something complex and esoteric like software quality. But consider the following: most of the large companies around the world today — ranging from banks to telecom vendors to automobile companies to consumer electronics firms — are actually thinly disguised software companies; and the same is true for most government agencies. The products and services provided by such companies are software intensive; and even if the software doesn’t account for the largest part of direct expenses, it’s typically the most crucial factor in terms of overall success and failure.

Considering the importance of software in so many companies, it’s interesting that senior managers– especially the CEO/COO and Board of Directors — are usually people with backgrounds in finance and accounting; sales and marketing; law; and (sometimes) hardware engineering (or mechanical engineering, aeronautical engineering, etc.). So, in my humble opinion, we should be electing, promoting, and rewarding people with software skills and backgrounds into more senior management positions. That doesn’t necessarily mean that I’d vote for Bill Gates as President … but it might lead to more successful results than electing a former movie actor as President.

Collaboration is something we hear a lot about in the Web 2.0 world, but you don’t hear much about it in traditional software development — at least not in the context of software quality. We hear mostly about software processes and methodologies, better tools and testing techniques, etc. But it seems to me that large software teams (or, perhaps more accurately, “software armies”) organized in a traditional hierarchical managerial structure have not worked very well. One reason is that the people in the senior technical managerial roles are often technically obsolete (e.g., their last programming assignment was in Autocoder on an IBM 1401), and thus incompetent to be giving technical instructions to the bottom-level technicians who are trying to write high-quality Java code for a complex distributed system. Another problem is the typical time-lag between the moment that a senior technical manager makes a decision (“the architecture for our system shall be X, and the programming language shall be Y!”) and the time it reaches the bottom-level technicians, by which time the decision may no longer be relevant.

So, we should be exploring peer-organized, grass-roots open-source development strategies — e.g., why is it that development efforts like Linux and Wikipedia have been so successful, when (to oversimplify things a bit) nobody is “in charge,” in the traditional sense of the word? The issue here isn’t whether Linux is better than Microsoft Vista, or whether Wikipedia is better than Encyclopedia Britannica; the issue here is that a traditional management-oriented person would have predicted that the Linux/Wikipedia organizational approaches would quickly disintegrate into chaos and anarchy. But they clearly have not done so; and while books like Eric Raymond’s The Cathedral and the Bazaar have given us some insights into the open-source development model, we need more analyses and investigations.

Also, we should realize that we not only need more collaboration within a software development organization, but also across the organizational boundary, into the marketplace. We need to get customers involved in R&D, product definition, documentation, QA, and technical support. The Web 2.0 people have been telling us this for the last couple of years, and people like Don Tapscott and Anthony D. Williams have been articulating the concept in new books like Wikinomics: how mass collaboration changes everything. The pharmaceutical industry is already making big investments, and reaping big rewards, in this area; the software industry needs to start listening.

Finally, on the technical side of things, we need to remember that the tradeoffs between functionality, time, people, cost, and quality are non-linear. If you compress the schedule for a project by, say, ten percent, chances are you’re going to suffer a disproportionately larger decrease in quality, assuming that you hold the cost, functionality, and people constant. Unfortunately, customers and senior management don’t understand that reality; indeed, most of them don’t want to acknowledge any tradeoff at all, and would prefer to accomplish shorter schedules by yelling and shouting at the developers to “Be more motivated!”, by which they mean “Work more unpaid overtime!”

In order to have a rational, mature dialogue about this issue (which may be difficult to do in any case, because of the politics — which is why my first proposal concentrated on the political issues), we need to make better use of existing software estimating models and tools. One of the best ones, though by no means the only one, is Larry Putnam’s SLIM model. Sadly, tools and models like this are used in only a small percentage of software development efforts.

So, those are my three suggestions for improving software quality. Somehow, I managed to articulate all of this within the prescribed ten minutes, but I’m not sure it made any sense at all when it was translated into Japanese.

The first chapter is numbered zero, for reasons I’ll let you discover on your own; Rosenberg begins with two vignettes about the excitement and frustrations of writing computer programs. The first one takes place in 1975, when he was a high school student programming a game called Sumer; the second takes place in 2000, when he was a 40 year old executive at Salon magazine, in charge of a software development effort to “revolutionize” the organization’s web site with “dynamic features,” the details of which are never explained. The first effort was all-absorbing, frustrating, but ultimately successful; the second effort was equally all-absorbing, more frustrating, and apparently successful at the last moment because of several all-night work sessions.

Rosenberg uses these two vignettes as a metaphor for the industry-wide experience that while the intellectual excitement of computer programming is undiluted after 25 years, the odds of success haven’t improved much; indeed, if anything, it’s gotten much more difficult to make today’s software work. The consequences, and possible solutions, to this dilemma are presumably the subject of the remainder of the book; and it’s obviously something he feels we must discuss. As he says in the final paragraphs of the chapter,

“Software is a heap of trouble. And yet we can’t, and won’t, simply power down our computers and walk away. The software that frustrates and hogties us also captivates us with new capabilities and enthralls us with promises of faster, better ways to work and live. There’s no going back. We need the stuff more than we can hate it.

…

Some dream of ripping down the entire edifice of today’s software and replacing it with something new and entirely different. Others simply yearn for programs that will respond less rigidly to the flow of human wishes and actions, for software that does what we want and then gets out of our way, for code that we can count on.”

Well, that’s fine — and I’m looking forward to what he has to say about this great intellectual dilemma. But I must admit that I’m already a little worried, for I’ve seen no indication that he’s going to focus on what some of us see as the essence of the problem. The problem, at least to some extent, is not better programming languages, better tools, better design methodologies, or better testing techniques. The problem is people, and the communication between people.

Consider the two vignettes at the beginning of the chapter. In the first one, Scott Rosenberg labors alone, as a nerdish 15 year old student trying to make the BASIC programming language manipulate the rules of a game that simulated a city-state in the ancient Fertile Crescent. He didn’t have to communicate with anyone other than himself; he didn’t have to schedule any meetings, he didn’t have to write any memos, and he didn’t have to worry whether the “programming team” of one person was sufficiently motivated to finish the task.

In the second vignette, Rosenberg is the Managing Editor of a high-tech magazine; he’s got a Vice President of technology reporting to him, who in turn supervises a “lead programmer, [who] after working around the clock for weeks on end and finally announcing that his work was done, had taken off for Hawaii on a long-planned family vacation.” But apparently the program didn’t work after all, and apparently the VP didn’t figure that out until it was too late. There are vague references toward the end of the vignette to other “developers” (plural), and implied acknowledgments of human-inspired breakdowns in testing, documentation, supervision, change control, and goodness knows what else.

Even today, one-person programming projects have a much higher likelihood of success than the “Mongolian horde” projects involving hundreds of developers (I recall reading somewhere that the Microsoft Vista project had 4,000 developers, though I can’t seem to find any supporting documentation for that number right now; still, even if it was only 1,000 developers, it’s still a horde). And a large percentage of the truly innovative and successful software products (e.g., Visicalc, Netscape Navigator, the initial version of Google, and YouTube come to mind) were built by small teams of only a handful of people. Because our tools and technologies have improved enormously over the past 50 years, a few really gifted people can sometimes develop systems of staggering size and complexity; but since our demands and desires for technological achievements sometimes grow even faster than our technologies, we still find ourselves forming huge armies of developers to create even more massive systems … and these often fail.

Maybe all of this will be acknowledged and discussed in subsequent chapters. But I took a quick look at the index and was disappointed to find no entries for “peopleware” or Tom DeMarco’s work. On the other hand, Gerald Weinberg (author of The Psychology of Computer Programming, and many other fine books) has an entry, as does the Psychology book itself; and there are several entries under the heading of “management of software projects,” as well as entries for several other interesting people who have some very perceptive things to say about software development. So that gives me hope for the rest of the book; I’ll continue soldiering on. (Update: a couple hours after initially posting this blog entry, Scott Rosenberg graciously emailed me to confirm that (a) he is indeed aware of Tom DeMarco’s fine work, even though he didn’t have a chance to acknowledge it in his book, and (b) he does indeed emphasize the importance of people, and communication between people, in subsequent chapters of his book. Now I feel greatly encouraged, and will indeed move on to the next chapter of Dreaming in Code with great enthusiasm!)

One other brief comment at the beginning of this review process: I’ve already stumbled upon an example of the inadequacy of “dead tree” publications, the advantages and benefits of Web-based publications of the same material, and the occasional inconsistency of the two. When reading through Chapter 0, I found a reference to a Web page maintained by the ACM (“Association for Computing Machinery” for the non-geeks out there) “that lists versions of ‘Hello World’ [the first and most elementary program that anyone writes in any programming language] in nearly two hundred different languages.”

Huh! I thought. Cool! Where the heck is it? There was no footnote on the page, no URL to the aforementioned Web page; and even if there had been one, it’s pretty hard to double-click a piece of paper and expect anything useful to happen. It was only later, when I started scrounging through the index in search of my friend Tom DeMarco, that I happened to notice a section at the end of the book called “Notes,” which contained end-notes for each chapter. There were ten such notes for Chapter 0, with lots of useful information, but none of it was mentioned or identified in Chapter 0 itself. Bummer, I thought. Some editor should be hung by his thumbs until he screams for mercy.

But then I had another thought: surely, thought I, someone as clever and erudite as Scott Rosenberg can’t be oblivious of the Web! So I typed the search phrase “Scott Rosenberg Dreaming in Code” to Google, and voila! the first item at the top of the list of 244,000 items found by Google was an entire website titled DreaminginCode.com. Book reviews by other people! A blog by Scott Rosenberg! Links to Amazon and Barnes-and-Noble, where you can buy the book! Everything you would want and need!

Indeed, there’s even a link to a section called “Endnotes,” which (among other things) I hoped would provide me with a clickable version of the URL to the ACM “Hello World” page. But, sadly, here’s what I found when I clicked on the “Endnotes” link:

Many of the references in Dreaming in Code are to online resources and Web sites. When the book is published, this page will contain a version of its endnotes with all the links “live.” I’ve been writing almost exclusively for the Web since 1995, and found myself frustrated with the impossibility of doing this in the book’s print edition!

Hey Scott! The book is published; I ordered my copy from Amazon just like every other mere mortal (I wasn’t one of the lucky few who got a pre-publication review copy). So where are the contents of this page? Feh! (Update: Scott Rosenberg emailed me to say that his book had only been in the stores for two days when I posted my critical comment. And he apologized for the delay in uploading an HTML version of all the EndNotes, pointing out that he has no staff or assistants, and must do it all by himself. Okay, I’ll apologize for being so impatient … but, hey, Scott, can’t you find any interns at Stanford or Berkeley who would volunteer to do this work gratis — or have they all been hired away by Google? Just kidding; we’ll all be very grateful whenever you get a chance to get this stuff onto your website.)

For those who really want to see all of that ACM code, the “Hello World” page is here. And there are only 193 languages in the list. But why quibble over the difference between 193 and “nearly two hundred”? After all, it’s only computers we’re talking about, and computers are forgiving, right?

Well, anyway, that should be enough to keep you busy for a little while. I’ll carry on with the next chapter as soon as I get a chance…

Updated to add:

Reviews of other chapters of “Dreaming in Code”
Preface
Chapter 1: Doomed
Chapter 2: The Soul of Agenda

Chapter 3: Prototypes and Python

Endnotes

“Your item on why software hasn’t got any better really resonated. My team at [a large insurance company] looks for way to improve methods, tools and practices. So, I have pondered this myself – particularly #12 (how do we explain this better?), #7, and number 5 (insurance is regulated at every level and with the advent of consumer heath plans – the envelope might be pushed)

“Here’s a few more that jumped out for me:

“13. We off shore our work and do not always specify quality. I was asked to join a conversation with our off shore company where we were asking them to re-structure some COBOL code to make it better. The conversation continued to talk about the amount of code and engagement dates until I stepped in and asked: How will you know you got back code restructured in a way that you wanted? Silence.

“14. We don’t do an effective job of re-use. Code (heck, requirements!) may be reconstructed for the same or similar functionality to 10 things we have already. Big organizations are not necessarily structured for effective software development. Even when they try – politics places a key group out under someone else’s control. (So, would you organize a very large group?) There are still a whole lot of siloed departments, and siloed projects where slices of work are rather small (cost concern) and focused (so we can get it quickly) and siloed directories with security so that if you are not in a very specific group (dept, project) you can’t get in. As a result there is precious little visibility in to what we have as an asset inventory. (And, yes, no $ incentives or scorecards incentives to do so).

“15. According to Myers-Briggs Personality Type Indicator tests, conceptual and abstract thinking is only about 10% of the population. So, principles would not be a natural mode of thinking for software folks (who often test in the “other” profile areas that prefer specificity and concreteness).”

Another colleague, Herb Krasner, wrote:

“On the question of “why haven’t we gotten any better?”, it is my belief that the question itself is based on a false expectation that software development is supposed to be easier than it really is.

It is my belief that software development was, is now, and in the future will be difficult and challenging. Turning concepts into artificial reality usually is. I still link back to the “No Silver Bullet” theory that the essence of software is in its complexity, changeability and conformity — that is its true nature.

“As I look at your dirty dozen explanations, I find that my beliefs mostly align with your reasons 3, 4, and 9 — but I just love your embedded reflection in item 10 (as you get older …). And you already know that a side point of my ROI talk is to solve the problem stated by your #12.”

Finally, software metrics guru Capers Jones wrote to me after he, Herb Krasner, and I participated in a “software best practices” conference in early November, and said:

“Thanks for your thoughts on the stasis in the software industry.

“Here is a tidbit from chapter 24 of the 2nd edition of “Estimating Software Costs” [scheduled to be published in 2007]. It summarizes an issue – too many mediocre choices.

“There is one other aspect of complexity that has a direct bearing on automated software cost estimating tools and also on benchmarks. As of 2007 the software industry uses some 600 different programming languages and creates about 120 different kinds of software applications each of which can contain about 23 different features. The software industry employs 90 kinds of specialists, creates 53 kinds of paper document, uses 43 different design methods, and measures with 38 different size metrics. Software applications are built utilizing 26 different development methods that include at least 35 different activities. About 25 international standards affect software projects. Software projects face 30 different kinds of risk factors. The software industry must also deal with 24 kinds of complexity, perform 23 different kinds of maintenance activities, and may perform 18 different kinds of testing. The combinatorial complexity of these topics is enormous. There is no way for either project managers or estimating tool developers to include all of these factors at the same time. It is obvious from the plethora of choices and alternatives in the software industry that we are groping for better ways of doing things, but have not yet found optimal approaches.”

I suspect there are still other explanations waiting to be articulated. And while all of this sounds rather gloomy, we should keep in mind that we have software today that simply didn’t exist 20 years ago. Yes, we had email and word-processors and spreadsheets back in the mid-1980s, but we didn’t have web browsers, or Google, or most of the graphics programs available on our PC’s today. But the bottom line is that we’re still encountering serious difficulties trying to develop large, complex software projects on time, within budget, and with an acceptable level of quality. And it probably won’t get much better anytime soon…

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.

1. Don’t fail to identify the key “players” who will ultimately declare “success” or “failure” for your project — you can deliver the required functionality, and you can do so on time, under budget, and with good technical quality, and still have your project declared a failure by a powerful stakeholder who has decided he doesn’t want your project to succeed for some reason. Similarly, you can deliver a subset of the required functionality, with lots of bugs, months behind schedule, and way over budget — and still have your project declared a success, if a key stakeholder is satisfied with the results. If you haven’t identified the key stakeholders and sources of power, your chances of success with anything other than a trivial project are minimal.
2. Don’t fail to clearly identify (preferably in writing!) what constitutes “success” for your project — everyone wants to deliver a defect-free system, with all of the features and functions requested by the user, on time and under budget. But which of these really matters to the person/persons who have the power to declare success? Sometimes it’s okay to be a week or two behind schedule; sometimes it’s not. Sometimes you can exceed the budget by a few million dollars; sometimes you can’t exceed it by a penny. You’d better figure out which of the criteria for success are “hard” and non-negotiable, and which ones are soft and/or negotiable at the last moment.
3. Don’t confuse “estimating” project schedules and budgets with “guessing” or “negotiating” — much of what we call “estimating” is a farce: even if we had adequate historical data with which to develop a “rational” estimate of the time, money, and people required to develop a system, that estimate would not be acceptable to the end-user or key stakeholder(s). What usually takes place is a form of negotiating, based on inadequate and incomplete information; unfortunately, what really takes place in many projects is a form of bullying, where the project manager is ultimately forced to accept a schedule, budget, and staff that he knows, deep in his heart, won’t be sufficient to get the job done.
4. Don’t ignore the non-linear nature of tradeoffs between people, time, money, and quality when negotiating key project parameters — if you tell the end-user, or key project stakeholders, that it will take 12 months and 10 people to develop a system, what happens when they respond by saying the system must be delivered in 6 months? In most cases, their initial negotiating position is to offer zero additional people; the implicit assumption is that your initial estimate was a bluff, or that it included a 100% “safety factor,” or that your staff should be willing to work 16 hours a day instead of 8 hours a day. Even if your end-user/stakeholders are generous, they’ll normally assume that the tradeoff between time and people (or any of the other project parameters) is linear: if they want the system finished in half the time, they have some vague notion that you’ll need twice as many people. But it doesn’t work that way; the tradeoffs are non-linear in nature, and you really need a sophisticated estimating tool (of which several are available in the marketplace) to calculate the details of the third-order polynomial equations that are involved. Meanwhile, tell your end-user/stakeholders to skim through Fred Brooks‘ The Mythical Man-Month for an explanation of this concept.
5. Don’t attempt to “freeze” user requirements; do expect “scope creep,” but don’t accept “requirements churn” — Anyone with experience developing a non-trivial system knows how unrealistic it is to expect end-users to freeze their requirements in the early stages of development. But the other extreme is just as bad: chaotic, uncontrolled “requirements churn” virtually guarantees that the system will never be sufficient stable that it can be used. You should assume that user requirements will continue changing at the rate of approximately 1% per months throughout the project; and you need to have some mechanism in place to acknowledge those changes, manage them (which means, among other things, prioritizing them), and incorporate them into the evolving system.
6. Don’t allow developers and key end-users to stop communicating with each other — one of the key elements of most XP/agile development methodologies is to encourage ongoing, intensive interactions between the developers and the end-users who will eventually be stuck with the system. Everyone understands this point, and most projects begin with a reasonable degree of interaction between the end-users and developers. But for a variety of reasons, there’s a common tendency for the two groups to start drifting apart as the project continues — the end-users are busy doing their “regular” jobs, and the developers often believe that they’ve learned enough about the end-user requirements to go off in a corner and start coding furiously. This is almost always a disaster, if only because the two groups typically fail to come back together again to participate in acceptance testing in a cooperative fashion. Keep them together, joined at the hip, throughout the entire project.
7. Don’t commit teamicide — most non-trivial projects require a team of developers and related specialists; the success or failure of the project depends, to some extent, on how well the team works together. But in many cases, any chances for successful teamwork is killed by idiotic managerial and bureaucratic rules and procedures. For details, see Peopleware, by Tom DeMarco and Tim Lister; for a more recent update, see “Teamicide Revisited,” by the same two authors.
8. Don’t ignore whatever software processes the project team has committed to — it’s hard to endorse a waterfall life-cycle and its associated processes these days; but aside from that, it doesn’t matter too much whether your project team decides to use XP, scrum, RAD, RUP, agile development processes, or whatever else strikes their fancy. The most important thing is that the team should agree, at the beginning of the project, which of the “standard” process activities will be eliminated, which ones will be followed on a cursory basis, and which ones will be followed with religious fervor (e.g., pair programming, writing acceptance test criteria before writing code, etc.). And once those details have been agreed upon, don’t abandon the process in the heat of battle, simply because everyone is “too busy” to follow the process. The result of such abandonment is usually anarchy, and it doesn’t end well.
9. Don’t skimp on risk management — trivial projects may not have any risks, but any interesting, non-trivial project is inevitably saddled with risks. You can’t make them go away; but you also can’t ignore them. I’m amazed by how many managers pound their fist on the table, and exclaim loudly, “I don’t want to hear about any problems unless you’ve got a solution!” … and then wonders why nobody on the project team tells the managers about such problems. Duh! The serious risks are the ones for which the project team members can’t figure out a solution — that’s why they want to bring it to the attention of the manager!
10. Don’t forget the importance of a “daily build” approach — project status indicators that consist of delivering piles of paper (test plans, requirements documents, architecture diagrams, use-case models, etc.) are better than nothing, but they don’t really show tangible evidence of progress. As (former) Microsoft Visual C++ manager Jim McCarthy likes to say, “The daily build is the heartbeat of the project — it’s how you know you’re alive.” If you don’t know what this is all about, check out the Wikipedia article here.

Project managers who follow these commandments may not deliver a “perfect” system, but my own experience indicates that they will have eliminated the major causes of project collapse and failure.

Let me know if you have your own list of “ten commandments.” We can use as much wisdom as we can get in this area!