I don't think you can actually "review" a book like this one. It's like reviewing Dostoevsky.

Sufficient is to say that this book is still highly relevant after 35 years, which is beyond any possible comparison. In fact, it doesn't bug you the least that the author speaks about new languages COBOL and PL/1 or programs being fed into a computer through a stack of punch cards. Because it doesn't matter, it's irrelevant to the matter discussed.

Which leads us to what the book is about. The book is really about the relationship between a human programmer and the programs he writes. The psychological aspects of programming, if it doesn't sound too obvious. And that did not change over the years. It is as helpful to a programmer today as I guess it has been at the time it was written. For a programmer to read this book is to increase self-awareness and understanding of the profession.

Neither very psychological nor very technical (on purpose, to encourage more people to read it), the ideas in this book come mostly from observation and there are plenty. See, the primary purpose of this book was to stimulate related research. It has apparently been achieved - as of now, it is referenced from all over the place as the major source.

A must read.

I think Wienberg must be spamming these reviews with a multitude of user names. That is the only explanation that can explain the four star average rating for this steaming pile of refuse. This is a book from an era when there must have been very low standards for 'popular' technical books. Weinberg is no psychologist, his observations are amateurish and ill informed. This book reads more like a 'best practices' work for the mainframe era. The most telling thing I can relate is my experience; after finishing a chapter I would read the chapter summary and not recognize a single thing from the chapter I had just read. The most laughable part was the coverage of programming languages. Wienberg is so completely ignorant of programming language research, even for that era, it's stunning. AND the man had (has) the gall to write on the subject as if he knows something. The most distasteful part of the book are the Anniversary Edition comments. They basically consist of Weinberg telling us that, he may not have been completely correct, but wasn't he amazingly prescient for the times? Gag. I'll never read another book by this author.

If you're a developer (referred here as a "programmer") and something's not going just right in your work or group, try reading this book to see if the situations are somehow familiar. The stories about non-technical factors that affect code quality and developer's quality of life are the originals from 25 years ago, with a few-page update at the end of each chapter. While there aren't punch cards and batch jobs anymore, the situations still occur. Try to find your parallels in modern-day software development, where the tools may be new but the people are very much the same. (Do your best to ignore the chauvinistic comments here and there left over from a male programmer of 1971, for which the author now apologizes.) Interesting thoughts at the end about how language and compiler design also affects ease of writing good code.

The purpose of this book is to study computer programming as a human activity, or its psychology. This was written in 1971, just after the pioneering days of programming had ended, when colleges began to issue degrees in computer programming. Its like a fossil of an extinct species. The ability to do programming well is a talent that not all have (p.3). Like other talents, it can be well-paid. But these costs are targeted by computer management. Weinberg believes programmers can learn by reading programs. How many managers would allow this?

The story on page 18 shows that simple logic is not only easier to code, but avoids the bugs that come from complexity. [I suspect the original programmers started with little planning or design.] Page 34 points out that OS/360 JCL isn't hard to use, its hard to learn. Using keywords may be easier, but its more verbose than positional parameters (another trade-off). The paragraph on 'egoless programming' may not be usable in areas with changing personnel, a management that plays favorites or encourages dissent (divide et impera). The point of "clear and understandable" (p.59) implicitly criticizes subtle and sneaky code, but doesn't address job security. [There is no mention of on-line debuggers that will execute a program statement by statement.

Having a referee to look over programming is more important during initial construction than later maintenance. The discussion of "raw trainees" overlooks other areas, like the military or a factory assembly line. There is a certain amount of time needed for training, depending on the complexity of the task. Nothing can change that (p.69). Since programming is done by humans, it will always have 'human error' (p.72). Page 74 proves the need for program review by a referee, and for a ban against modifying executable code (non-reentrant). Technical arguments are often a mask for political power, and its rewards (p.78). The story on page 88 doesn't tell who pulled the plug! Chapter 5 concludes with the problems in 'herding cats' (p.91). The story about a dissatisfied programmer doesn't consider the idea that the manager may have felt threatened and acted accordingly (pp.97-98).

Doesn't Weinberg realize that his democratic team sounds like socialism? Has anyone anywhere tested the "simple maxim" on page 100? Page 104 explains the hidden agenda of polling: say something enough times and people will believe it. Weinberg should know that the adversarial relationship between testers and programmers is needed to prevent any problems from being overlooked (p.108). The "success of the Austrian Army" (p.108)? The story on page 110 doesn't ring true; aren't project managers downgraded if they're "too technical" (loss of objectivity)? Page 137 reminds me of those days when a bug could be due to hardware error.

The story on page 157 overlooks the fact that a big expensive project could be canceled if the obvious question was raised. The comment on labels is very true, but doesn't mention typing errors as another source of bugs (p.163). Weinberg's comment that re-writing a program is far easier than the first writing (p.165) explains the 'success' of the Structured Programming Fad in the late 1970s: "write a program in one day instead of a week". Wasn't the article on palindromic programming a hoax (p.174)? The pages on Linearity (pp.231-232) are very informative, but don't mention the effect of punched cards on the use of GO TO statements (adding new coding to the back of the deck). The problem of format errors can be handled by a one-page memo for each programmer (p.236). Are Weinberg's comments on COBOL (p.240) valid afterwards for COBOL II? The bug (typing error) on page 249 could be caught by a code reviewer. The story about "hasty punching" (p.260) does not mention the need for teaching programmers how to type for efficiency and productivity. CRT terminals give instant feedback. Batch allows code reviews, on-line gets faster results (p.261).

The topic of 'Documentation' doesn't distinguish between that written for the user of a program, and that written for program maintenance. A well-documented program should have comments where needed; the programmer is usually NOT the one to decide where it is needed (code review). Another method is to have the original programmer responsible for all future maintenance. Note how "documentation" is not defined here (p.262). As I remember it, the author left his University job after this book was published. What did that suggest?

This book has a wealth of information on how programmers work when in groups, and is a useful read for both managers and individual contributors alike. Many of the fuzzier, less-quantifiable people issues that affect programmers are covered well.

However, it really suffers in three ways:
- All of the examples and technology details are dated to the point of distraction.
- The typography appears to be photocopies of the original text, and really looks terrible. Couldn't they have reset it?

- Not a lot of concrete advice.