The Psychology of Computer Programming, Gerald M. Weinberg, Van Nostrand Reinhold Company, New York, 1971. Hardbound, 288 pages. Personal acquisition date: 17 Oct 1978. Original edition out of print.

The Psychology of Computer Programming (Silver Anniversary Edition), Gerald M. Weinberg, Dorset House Publishing, New York, 1998. Softbound, 292 pages. Personal acquisition date: unknown. Currently in print (and in ebook form).

Seminal work; highest recommendation.

===========================

(All quotes and citations are from the 1998 Silver Anniversary edition, which contains the unedited text and original page numbering of Weinberg’s original book interspersed with his observations 25 years later using a different pagination scheme.)

If The Mythical Man Month (Frederick P. Brooks, Jr., 1975/1995) is the book that most IT managers own but few ever read (and even fewer follow), The Psychology of Computer Programming (Gerald M. Weinberg, 1971/1998) is the book that almost nobody nowadays owns…at least, nobody under a certain age. And that’s a tragedy, because Weinberg wrote one of the first and still one of the best works on the human factors in IT project management and software engineering.

I bought my own first copy of Weinberg’s book in the fall of 1978, nearly 35 years ago, just a few months after joining General Dynamics with my freshly-minted BS in computer science from BYU. Weinberg’s book had a tremendous impact on me and forever changed my view of software development from a technical activity to a human, social activity. In fact, Weinberg’s first sentence in his first chapter is just that: “Computer programming is a human activity.” That single insight — with all it implies — is something that the IT industry seems to re-discover on a regular basis and then forget again just as quickly as it seeks the ever-elusive magic amalgam of technology, methodology, and language (with minimum pesky humans) that will make software development fast, cheap, and good. Weinberg touched upon that very quest early on in the book as well :

[1971] Over the years, executives have backed their desire to eliminate programmers with staggering funds. Dozens of simplistic schemes have been heaped with money and praise on the promise — as yet not kept — of going directly from a sales proposal to a working data-processing system. (p.4)

[1998] The only thing that’s changed here in twenty-five years is the fact that the funds dedicated by executives to eliminating programmers from their payrolls have become far more staggering than I imagined back then. (P1.i)

Furthermore, Weinberg got to many of Brooks’ key insights four years before Brooks published The Mythical Man-Month, including touching (in a slightly different way) on the most famous one: adding more people does not get a job done more quickly, and using exactly the same analogy that gave Brooks’ book its title:

For example, certain programming work cannot be done by a team of trainees, no matter how large, so that doubling the number of “warm bodies” — as they are so often called in the trade — still will not get the work done. Schedule is similarly limiting — we need only cite the apocryphal experiment which tried to make a baby in one month by putting nine women to work on the job as a team. (p. 68)

Here is just a very small sampling of other insights from Weinberg’s book (my comments are in brackets and italics):

Fisher’s Fundamental Theorem states — in terms appropriate to the present context — that the better adapted a system is to a particular environment, the less adaptable it is to new environments. (p. 21) [Thus anticipating the core problem in the entire OO/reuse movement of the 1990s]

The organization chart is a nice toy for a manager, but little programming work would ever get done if interactions among programmers had to follow its narrow, straight lines. . . . But human interactions are never narrow, never straight, and hardly ever in the directions shown on an organization chart. Many serious mistakes have been made in imagining that formal structure was the only structure in an organization. (p. 48)

A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. . . . And let there be no mistake about it: the human eye has an almost infinite capacity for not seeing what it does not want to see. (p. 55) [Weinberg then goes on to discuss his somewhat controversial (at the time) concept of 'egoless programming', which really boils to to getting other programmers to review your code, now considered to be a best practice: 'many eyes', pair-programming, end-of-day review swaps, etc.]

[By having programmers review each other's code:] Not only is the variation in debugging time reduced, but since there is more than one person familiar with the program, it is easier to get realistic estimates on the amount of real progress that has been made. It is not necessary to rely on a single judgment — and of the person least likely to be unbiased. (p. 59) [Weinberg goes on to note that you generally end up with more readable code, and you lower the impact of turnover within the programming group, since more than one person understands the code in question.]

Managers tend to select themselves from the “aggressive” component of society and have difficulty appreciating the fact that other people do not completely share their goals of money and prestige. They are especially at a loss to understand the smooth functioning of a programming group based on mutual respect for individual talent and cooperating in the common cause. Instead, they tend to view people as working for money or under threat — and they themselves do. (p. 61) [Some things are timeless.]

So many failures to meet programming deadlines can be traced back to an initial schedule and plan of attack which assumed the most optimistic conditions — no days lost through illness, no machine trouble, no compiler problems, no “impossible” bugs. Because each of us has had the experience of, say, a six-month period in which everyone on the team was in top health or there was no machine trouble or there were no compiler problems or there were no “impossible” bugs, we can slip into imagining — if the price is right — that we can have a six-month period in which all of these fortunate circumstances happen at once. (pp. 68-69) [Again, plus ça change...]

[After a story of upper management trying -- unsuccessfully -- to force a team leader into accepting an impossible schedule:] Did Harold lose his job? He didn’t, in this case; but that wasn’t really important, for he knew he could get another at least as good. If [keeping his job] had been important, he wouldn’t have been able to do what he did. One of the paradoxes of leadership is simply this: only the leader who is ready to step down has a real chance of success. (p. 85)

It is possible to be too smart for programming — if the person is not smart enough to use his intelligence to modify his social behavior and methods of communication. (p. 88) [Yes, there have always been prima donnas.]

In a sense, a programming project or team is like a river which remains the same river even thought its water is undergoing constant change. Many project managers are unable to grasp this view of a project. Their view of the project’s structure is, instead, much like that of a house — a structure that might collapse should one of the beams be removed. Their actions with respect to the people in the project — especially so-called “key” people — reflect this static view, often with disastrous consequences. (p. 96)

[Telling a story about the 'filtering' process of reporting project progress up a chain of command:] The net result of six or seven stages of such filtering was a report that monthly presented a consistent forward progress, a few areas slightly behind or slightly ahead, a few problems solved from last month, a few new problems, and a few problems still open. There was, in short, no measurable relationship between what had been reported at the bottom and what came out the top. (p. 101) [Thus describing what I years later termed "the thermocline of truth". Note that Weinberg himself commented on my post and argued for the gradual layer-by-layer changes that he describes in his book; I countered with two real-world examples where a single individual was responsible for most of the filtering.]

Pressure from higher up is classically recognized by management manuals as both the way to get work done and the way to destroy a reporting system. (p. 103)

Any testing group is also put into a difficult relationship with other groups, because it is their job to criticize. (p. 107) [Thus capturing the classic tension between QA and development, though he goes on to describe ways to overcome it.]

When a supervisor is responsible for work he does not understand, he begins to reward workers not for work, but for the appearance of work. Programmers who arrive early in the morning are through to be better programmers than ones who are seen to arrive after official starting time. Programmers who work late, however, may not be rewarded because the manager is not likely to see that they are working late. Programmers who are observed talking to others are not considered to be working, because the manager has an image that programming work involves scratching out secret messages to the computer. (p. 110) [Again, some things just don't change.]

Programs, like any other man-made objects, are designed — or should be designed — with a definite lifespan and scope of application in mind. . . . a program should have neither overdesigned or underdesigned parts. Yet it is an occupational disease of programmers to spend more time on those program parts that present, for some reason, the most intellectual challenge rather than on those that require the most work. (p. 126)

Another fallacy which we shall have to lay to rest is that “programming” is some sort of uniform effort requiring a set of uniform talents. For the professional, at least, the job from getting to specifications to delivered program demands various kinds of work, wihch, in turn, demand various talents. (p. 132) [Something which I subsequently discussed in the 'talent' section of my TEPES post a few years back and some 37 years after Weinberg's observation.]

Programming is often described as a process moving from problem definition through analysis to flow diagramming, then coding, followed by testing, and finishing with documentation. Although this rough view contains some truth, it distorts the truth in several ways. First of all, the actual sequence is not so fixed, because, for example, documentation may precede testing, coding, flow diagramming and even analysis. Second, not all steps need to be present, as when we are recoding a program for a new machine or language. Thirdly, it need not be a sequence at all — and, in actual practice, rarely is. Who has not experienced a problem definition that changes as discoveries are made in analysis, flow diagramming, coding, testing, and documentation? Or who has ever seen a flow diagram that remains unmodified throughout the coding — or code that remains unmodified throughout testing? (p. 133) [Yes, Weinberg in 1971 is dismissing the 'waterfall' model and arguing not just the need but the inevitability of incremental/iterative development.]

Although the average programming manager would say that intelligence is more important that personality in programming success, very few could cite cases of people who turned out to not to be intelligent enough to program, but everyone knows of cases of people who were not temperamentally suited to the programmer’s job. It is in this sense that we can assert that personality is more important than intelligence in programming. (p. 148)

[Regarding ideal personality traits for programmers]…we can probably say with assurance that someone without the ability to tolerate stressful situations for a period of a week or more is not good programmer material…people who are not in some measure adaptable to rapid change will probably have trouble as professional programmers….one of the most easily identifiable personality needs in programming is a modicum of neatness. We are not speaking here of personal grooming…What we mean is a slight compulsion to keep one’s papers in order, without which the computer’s paper-generating capacity inexorably leads to grief….Another essential personality factor is at least a small dose of humility. Without humility, a programmer is foredoomed to the classic pattern of Greek drama: success leading to overconfidence (hubris) leading to blind self-destruction….The other side of the coin of humility is assertiveness, or force of character. A programmer’s job is to get things done, and getting things done sometimes requires moving around obstacles, jumping over them, or simply knocking them down….Last among the essential personality traits for programming, we might list sense of humor. The computer “doth make fools of us all”, so that any fool without the ability to share a laugh on himself will be unable to tolerate programming for long. (pp. 149-150) [Still probably one of the best summaries of what makes a great programmer, and particularly a great co-worker on a programming team.]

One of the best known and accepted results of motivation research is that increasing “driving force” will first increase performance to a maximum, beyond which addition of further driving forces will quickly drive performance to zero. (p. 182) [Can you say "death march", boys and girls? I knew you could.]

The fear of new things, the expectation of failure, and the reluctance to admit weakness all have a direct retarding effect on learning, whether in a formal classroom setting or on the job. (p. 191)

A programmer would not really be a programmer who did not at some time consider his program as an esthetic object. This part is not quite symmetrical; that part is clumsy and doesn’t flow in an appropriate manner; the whole thing does not look proper on the page. To be sure, it is fashionable among programmers to be rough and tough and pragmatic, but deep down each programmer knows that it is not enough for a program just to work — it has to be “right” in other ways. Later, when we discuss language design and program testing, we shall see that the correlation between the esthetic and the pragmatic value of a program is not accidental — the more pleasing to the eye and mind, the more likely to be correct. (p. 209) [Thus anticipating the whole emergence of the "elegance" value in software design and implementation.]

What these quotes — which represent a tiny fraction of the book — don’t contain is one of Weinberg’s greatest strengths: stories. Weinberg illustrates point after point with real-world stories that — aside from the archaic technology — sound very contemporary and very true to life, and are usually entertaining to boot.

Weinberg also has questions for IT managers and for programmers themselves at the end of each chapter. As he himself notes, most of these hold up very well (though there are what he terms some “hilarious exceptions”). Here are some examples

[For managers:] On what basis do you reward programmers? Are certain of your criteria mutually contradictory, as in asking for efficient but general programs? How explicit are you with your programmers in indicating what you are looking for in their programs? Or do you just tell them that you want the programs to be fast, small, neat, easily modifiable, errorless, and done in a week? (p. 25)

[For programmers:] When you have just found a bug, do you ever sit back and try to trace out the paths you took in your mind? Try doing this on the next bug you find, and write a brief report or outline on what you find. (p. 40)

[For programmers:] Do you refer to your work as “my” program? Try passing one week without using the personal possessive in reference to programs, and take notes on the effects you observe. (p. 65)

[For managers:] Do you ever do things to try to inflate the appearance of your technical competence in front of the people who work for you? Describe some of these incidents, and also some incidents in which it was discovered that your technical competence was in at least one respect inferior to one of the people who work for you. What were the consequences of that discovery, and do they justify attempting to cover up? (p. 92)

[For programmers:] Has your manager ever done anything to make you doubt his honesty? If so, describe the incident, what ultimately happened to your doubt, and how your work was affected. (p. 93)

[For managers:] Which do you reward most, accurate information or pleasing information? Do your programmers know what the information you require is used for? Do they see the final reports which are the destination of their information? If not, why not? (p. 114)

[For programmers:] Have you ever yielded to group or managerial pressure against your best technical judgment? Describe the situation and the consequences. (p. 115)

[For programmers:] Make a list of things that your software does for you that fifteen years ago you would have have to do for yourself. Or don’t you know anything about what software was like fifteen years ago? Do you think a professional should know something about the history of his profession? (p. 138)

[For managers:] Do you use any aptitude tests now in choosing programmers, or does your personality department use them? If so, what do you know about their validity? Do you make any effort to validate them by evaluating programmers after a period of time on the job? What methods do you use for this evaluation? How convinced are you of their effectiveness? (p. 177) [Still very relevant questions, particularly for the organizations that like to use the 'brain teaser' approach to interviewing programmers.]

[For programmers:] Recall from your experience a “tiny” error that had a big ultimate cost. What debugging tools or techniques could have prevented that error? Would their cost have been greater than the cost of that one error? (p. 271)

Weinberg really was there first with an overarching view, set down in nearly 300 pages, of the human and social factors that affect software development and project management. As the excerpts above show, his observations remain utterly relevant for today. Professionally, I have been dealing with troubled or failed IT projects, either as a consultant or as an expert witness, since 1995. What I can tell you is that Weinberg and Brooks (whose book I’ll review next) pretty much nailed all the core issues some 40 years ago. During those four decades, tens of billions of dollars – if not a great deal more — have been wasted on failed or sub-performing IT projects. A lot of that money lost — both directly and indirectly — could have been saved if folks just read — and believed, and followed — these “old” books. ..bruce..

TABLE OF CONTENTS (adapted from the 1998 Silver Anniversary Edition)

PART 1. PROGRAMMING AS HUMAN PERFORMANCE

1. Reading Programs

2. What Makes a Good Program?

3. How Can We Study Programming?

PART 2. PROGRAMMING AS A SOCIAL ACTIVITY

4. The Programming Group

5. The Programming Team

6. The Programming Project

PART 3. PROGRAMMING AS AN INDIVIDUAL ACTIVITY

7. Variations in the Programming Task

8. Personality Factors

9. Intelligence, or Problem-Solving Ability

10. Motivation, Training, and Experience

PART 4. PROGRAMMING TOOLS

11. Programming Languages

12. Some Principles for Programming Language Design

13. Other Programming Tools

PART 5. EPILOGUE

Progress, far from consisting in change, depends upon retentiveness….Those who will not remember the past are condemned to repeat it. (The Life of Reason, 1905)

In my opinion, most of core issues in software engineering and IT project project management were identified decades ago, but our industry suffers from vast institutional ignorance of these works — ‘ignorance’ both in the sense of ‘unaware of’ and ‘paying no attention to’. As I once said in a rather interesting setting¹:

Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don’t fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded.

To that end, and because I have not been posting much here, I am introducing a new series of posts: Readings in Software Engineering, or RISE. Each post will cover one book (including subsequent editions). I will give what context I have for the book, then quote interesting or relevant excerpts from the book, followed at the end by the book’s table of contents. My intent is not to present “one page summaries” of these books, as are often found for various business books; instead, it is to pull out relevant quotes, in the authors’ own words, in hopes that you’ll actually track down the books and read them yourselves.

¹In testimony before Congress in 1998. Long story, had to do with Y2K.

My latest Baseline column  is up, and it talks about why you should read these five books now, if you haven’t already…and if you have read them, you should probably re-read them.  ..bruce..

The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.

Feedback is always welcome.

Categories: managerial

The impulse to constantly add new and incremental features to a software program certainly isn’t unique to modern software develoment, or to a particular technology or methodology. It derives largely from three sources. Upper management and marketing want, and sometimes need, those additional features to win a customer, to better position the product against a competitor, or to better justify the expense of an in-house project. Engineers often find it far more fun, more interesting, and more rewarding to add or extend features than to make existing features work completely and perfectly. And customers supply a constant flow of demand for new and improved functionality.

The problem is that many modern technologies and methodologies intensify all these tendencies. With a decent software design and implementation, based on current technology, it can take literally only a few minutes to add or extend features. Frankly, that’s the payoff that lures many engineers to modern technologies in the first place: They get to do really neat stuff, do it quickly, and impress the boss while they’re at it. The boss, having seen how quickly engineers can extend or create functionality, doubles or trebles the list of must-have features. The technical manager, caught in the middle, wonders how to deal with all this.

Symptoms

Engineers focusing on adding new features instead of getting old ones working completely. Upper management passing down long (or even short) lists of additional features when the engineering schedule will be hard-pressed to accommodate the current ones. Customers failing to distinguish between what they’d like and what they’re willing to live with.

Consequences

Features that don’t work as completely or well as they were intended. Missed milestones and schedule slippage.

Detection

Review all existing features with the engineering team and get an honest assessment of where each feature is and what it will take to complete it. If necessary, do a design and code review for each feature. Compare the documented “essential features” list—and the schedule required to complete them—with the current feature set as well as those proposed by engineers and upper management, and find where the differences are coming in.

Extraction

Nothing fancy here: Get the absolute “drop dead” release date for the software and work backward from there, allocating time to design, implement, debug, and test each feature that is not yet completed. Show everyone (especially customers) the gap between the time and resources allocated those required for just the currently planned and requested features. Use whatever process works in your company for performing feature triage: keeping those that are absolutely essential, dropping those that can wait for the next release, and negotiating on the others.

Prevention

Use the process given in Extraction before a line of code is ever written. As features are proposed, collect them in a list, but do not allow any work on them. At intervals, repeat the process: You might have time (or need) to schedule some of the proposed features, but you may well have to drop previously required ones.

As with a prior pitfall on features, this pitfall is so an obvious and well-known that I’m almost embarrassed to include it here. Again, it is still so common that I must.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

Categories: managerial

Why would the use of a new technology or methodology (the “TOM”) cause managers and developers to neglect or even abandon solid software engineering practices? Because those practices are under pressure from the start. Many engineers don’t know them and aren’t willing to spend (or aren’t given) the time to learn them. Those who do know them often aren’t willing to spend (or aren’t given) the time to practice them. Technical managers, who often do understand such techniques, find themselves caught in a vise, trapped between ever-increasing (and possibly unrealistic) demands of upper management and the productivity level of the engineers they supervise.

The introduction of a new TOM can cause a new set of problems. Upper management, having read articles about the benefits of this particular TOM, may see it as an opportunity to increase demands. Developers, already under pressure to produce, milk the benefits of the TOM for all they’re worth and may find even less incentive to focus on solid software engineering. And the technical managers in the middle have to cope with the specifics of the TOM while still fighting the software engineering battles.

Symptoms

Upper management expects the TOM to immediately shorten the software development lifecycle and is unwilling to allocate the necessary time and resources pilot projects. Engineers neglect common sense and best practices, feeling instead that the TOM somehow magically supersedes both. Unrealistic expectations from upper management puts pressure on the development team, resulting in even more shortcuts.

Consequences

Failure to achieve expected benefits of the TOM, possibly leading to (unwarranted) rejection of the TOM for future projects. Delayed, buggy, and/or failed projects.

Detection

It’s usually not hard to detect the pressure from upper management; indeed, the problem is resisting the pressure. As for the engineering-level problems, the best detection comes from regular team meetings and project reviews to go over standard (TOM-independent) software engineering practices.

Extraction

This pitfall is a hard one to get out of, because upper management needs to allocate more time and resources, and the engineers need the self-discipline and education to change how they’re doing things. The key is to educate everyone about the benefits of good software engineering — established practices, predictable schedules, and higher quality — and then work the TOM into that setting.

Prevention

It is sad that there is often so much resistance to doing things right in the first place. The approach is direct: realistic scheduling, definition of engineering standards, and enforcement of engineering practices. For starters, make everyone — especially upper managemen t– reads The Mythical Man-Month by Frederick P. Brooks. Then refer to it again and again as these problems arise.

References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political

You know the drill. By hook or crook, through long weeks and late hours and ruthless compromising, you finally deliver the project. It’s finished, it’s out the door, and you have taken a few weeks to remind yourself what real life is like. Now you have the opportunity to go back and make right all the hacks and shortcuts and ugly patches you used to get version 1.0 of the project to the customers. Besides, having done the project once, you now have a far better idea of how it should have been done in the first place. You rub your hands together and…

…you are handed a list of new features required by customers or potential customers for version 2.0 of the project, which has to ship far sooner than you would have thought. After some study, you realize that you’re not going to be able to deliver all those features within the required time frame — and even as you realize that, more features get handed down.

Your plans for cleaning up the code and the architecture are rapidly getting pushed off to version 3.0, and you really wonder whether things will be any different then.

Chances are, they won’t.

Why does this happen so often? There are several reasons, really. One may be economic necessity. Your company (division, group) may have to fund itself, which means that sales have to be sufficient to meet all expenses, including your salary and benefits. If that’s your situation, then don’t worry as much about this pitfall; architectural purity is nice, but a paycheck is better.

Another, less acceptable reason may be a short-term focus on the part of upper management. Determined to milk a current market opportunity and concerned primarily about next quarter’s results, they may not be receptive to an engineering investment that would yield more in the long run at the expense of smaller profits right now.

A third reason — not necessarily exclusive of the other two, and sometimes justified — is a suspicion on the part of upper management that engineers are more interested in doing something “cool” or “elegant” than in doing something profitable. What upper management may not understand is that elegance — architecture and code that are concise, yet clear and comprehensive, tending toward orthogonality — always pays off. Always. The only question is how soon and how much, and that is the fulcrum for the balancing act of the technical manager. Ironically, when the engineering staff is able to rapidly deliver the features requested by upper management, it is often because of a previous investment in elegance; likewise, when features take a long time to implement or bugs take a long time to fix, it’s often because of architectural gaps and past short-cuts.

Symptoms

Constantly having to push engineering work into the next planned release and not the current one.

Consequences

The cost of adding new features or extending current ones goes up, not down, over time. The program gets larger, less stable, and less cohesive. Bugs multiply, possibly causing a customer backlash.

Detection

Sit down with upper management and detail the engineering work that needs to be done. Indicate what impact this will have on the current list of desired features. See what kind of reaction you get.

Extraction

It ain’t easy. The reaction you get under Detection should give you a pretty good idea of what things will be like. There are two approaches, which should probably be used together. First, actively work with upper management and customers to determine which features are absolutely necessary and which are merely desirable — ones they could live without until the next feature release. It’s critical to talk directly with the customers, because they may not have done their own prioritizing; the list you get from management may reflect everything from essential requirements to blue-sky wishes.

Second, build engineering cleanup time into each feature so that an engineer allocated four weeks for a given feature spends, say, three weeks on the feature and one week on architecture.

Prevention

Besides using the steps described above in Extraction, you need to emphasize the need to make the proper ongoing engineering investment in order to gain the desired benefits, particularly if a new technology or methodology is involved. This means investing the time to educate management and customers, to set proper expectations, and (if possible) to run a trial project to demonstrate the process.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

CATEGORIES: political, architectural, managerial

While discussing the challenges of software development with Taligent trainer Tom Affinito back in the mid-1990s, I mentioned — citing Fred Brooks — the need for a chief architect. Tom immediately responded, “Yes, and ultimately architecture is a political act.”

That observation has stuck with me ever since. Unless you are both sole architect and sole implementor — and maybe even then — architecture is a political act, and it is especially true in development groups of any size. Developers like to think themselves above politics. Not so; they are as human as anyone else. Developers can be quite political and will use a variety of techniques, good and bad, to achieve their ends: persuasion, hyperbole, fear-mongering, caucusing, lobbying, consensus building, rumors, backbiting, leadership, intimidation, sacrifice, tantrums, threats, and subversion, to name a few. The fact that developers are generally very bright just increases the effectiveness of whatever techniques they use.

Architecture is the lodestar of developer politics because it is ultimately the most prestigious role in software development. Brooks goes to great lengths (and rightfully so) to assert the intellectual and creative challenges of implementation, noting that architecture is not the be-all and end-all. Still, it is Frank Lloyd Wright’s name that remains attached to the structures he designed, not the name of the contractors who built them. Or, to update an old programming joke, the verb “to develop” is conjugated this way: “I architect, you implement, he tests.”

Yet we may fail to recognize or acknowledge this situation and its implications. Why? First, we want to believe that all developers have (with regard to the project) the same intentions and goals. Second, we want to believe that the best course is the one that is obvious to us and that everyone else will agree with that. Third, we don’t want to have to deal with politics ourselves, particularly politics that can lead to confrontations.

Symptoms

Assuming — without verification — that all other members of the development group have the same goals, ideas, and talents. Not wanting to assert architectural issues. Finger-pointing as design problems arise.

Consequences

Hidden or overt team dissension, leading to poor morale and lack of cooperation as well as a weakened architecture.

Detection

Ask yourself these questions:

• Who is the chief architect of this project?
• How well do the other developers support the chief architect?
• How effective is the chief architect in her role?
• What are the obstacles she faces?
• What are all the political issues involved?

Answering these questions should go a long way toward determining whether you have underestimated the politics of architecture.

Extraction

The first issue to address is that of authority commensurate with responsibility: if there is a chief architect on the team, does she really have the authority to compel adherence to the architecture? This kind of authority is different than being able to say, “Do this or you’re off the project,” which often leads to subtle or overt rebellion by team members. This kind of authority accrues from several factors:

• a proven track record
• respect from teammates
• support from technical and upper management
• a mutual pact with the developers that the chief architect will give serious consideration to all their ideas and suggestions but that they will abide by her decisions
• a willingness to give in on the small things so that she can hold her ground on the big things

Beyond that, healing a team that is experiencing jealousy and dissension is no easy feat, especially when you’re in the middle of a project. Books and seminars on team-building abound; study, learn, and apply.

Prevention

Go through the questions in Detection but cast them in the future tense. Then, as with Extraction, proactively work to build the team and establish the authority of the chief architect.

Contributor/References

Webster, from Pitfalls of Object-Oriented Development (1995).

…the computer-operated baggage system has crashed and luggage is now being sorted manually before being loaded on to planes.

Twelve return flights to short-haul destinations have been cancelled. . . .

In just over a week the £4.3 billion investment has seen an unimaginable series of PR catastrophes.

Around 19,000 lost bags had to be transported to Milan to be sorted, hundreds of flights have been cancelled, and thousands of furious passengers have sworn they will never fly BA again.

A lack of staff parking and faulty IT systems started the rapid descent into terminal chaos which has seen BA suffer a 5% fall in business class passengers and left it with a £16 million bill.

This, of course, will remind those of us who track such things on this side of the Atlantic of the 10-year failed effort by United Airlines to automate the baggage system at Denver International Airport. One can only hope that our British cousins get their problems solved and solved a bit quicker. ..bruce..

Atos Origin is the information technology partner for the International Olympic Committee (IOC) with the job of designing, building and operating the invisible IT infrastructure that supplies results, events and athlete information to the media, spectators and the world.

It also designs the platforms for accreditation, transportation, hotel accommodation and other services without which the Olympics would fall apart.

On the 11th floor of Digital Beijing, a banner trumpets the slogan “At the Olympic Games, there is no second chance.”

Known and unknown risks are analysed and every system is backed up by a plan B, plan C, or even a plan D.

“We have a very high degree of redundancy (backup),” said Patrick Adiba, the firm’s vice president responsible for the Olympics and major events.

That backup includes an entire replica data centre set up at a secret location elsewhere in Beijing that will kick in if the main centre fails.

“We just have to be ready with a response to known and unknown problems,” said Adiba.

Atos Origin has been running the IT platform for every Olympics since 2002 Salt Lake City Winter Games and has signed on to do the same for the 2010 Vancouver Winter Games and the 2012 London Summer Olympics.

Note at least three key success factors that appear in the brief excerpt above:

• A high degree of redundancy in systems and processes
• A strong focus on testing, again for both systems and processes
• A vendor who has performed this exact same task (running an Olympics) multiple times

All things to keep in mind for your next large-scale IT systems development effort. ..bruce..