Gerald M. Weinberg
1 Retrospective on Pioneering Days
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?
2 Good info on collaborations, but short on details and dated
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.
3 How to understand your friend the programmer
Recently I was working with a group of professors who were rethinking the programming curriculum for Japanese computer science students. They knew what they wanted their students to learn, but they struggled in knowing just how to accomplish the skill instruction. I understood their problem, but only minimally. They should have recommended Weinberg's book because it really captures the tensions that are played out for teachers, students involved with programming, and it would have helped me make more informed colleague. As one interested in education and designing learning environments, I learned a whole lot about the complexity of studying/developing programming and programmers, and Weinberg increased my empathy for my computer science colleagues and their students. This book gives a view from a experienced programmer and instructor and depicts the challenges that programmers face. Chapter 12 on the principles for programming language design would have been helpful for our group; and this book covers many other related areas like group work, the variation of challenges, problem solving, instruction and more. Weinberg's great contribution however, is to highlight how the human factors such as personality and intelligence influence how programmers go about their tasks. I was turned on to this book through Gause and Weinberg's other book, "Are you lights on!" Both books are highly recommended. I have come to understand my programming friends a whole lot more because of reading this book, and am able to be more sensitive to my colleagues and engineering students are struggling with master this skill. When programming instructors, friends or students have bad days writing code, or keeping their sanity, I can suspend judgment, knowing a bit more of the problems he/she is working with. I recommend it for these reasons.
4 Timeless Insight into the Mind of the Programmer
The book's present-day relevance was amazing. The similarities in the behavior and interaction of the programmers of today and the programmers of old provides a unique perspective. This perspective highlights what makes some individual programmers and programming teams succeed regardless of the techology or decade they're working in.
Because of my background in psychology and my more recently acquired expertise in programming, this book quickly found a special resonance with me. Weinberg's grasp on both programmer attitudes and the psychological framework make this book one-of-a-kind.
5 A must for every professional
Some younger programmers may get impatient with the Weinberg's references to obsolete activities, such as keypunching and submitting a debugging run, but they shouldn't stop reading. Nearly every page of this book conveys valuable insights into the nature of programming. The book is readable and entertaining, a professional book you'll read for pleasure and re-read. Weinberg adds no new chapters, nor does he edit obsolete content. Even the pagination is the same as in the original. Instead the Silver Anniversary Edition appends to each chapter a "Comments on the chapter" section in which the author relates the content you've just read to the world of today.
6 Silver anniversary edition hits gold
The silver anniversary edition is an updated version of the classic work originally published in 1971. How can this still be relevant? Easy: people haven't really changed.
Weinberg did something courageous in his updated text. Instead of whitewashing history, he let his original text stand, unedited, and simply commented on each chapter separately. The approach worked for me, making an already entertaining text a joy to read.
What is all this about? Weinberg writes "This book has only one major purpose--to trigger the beginning of a new field of study: computer programming as a human activity, or, in short, the psychology of computer programming. All other goals are subservient to that one." Indeed there has been much study of computer programming as an art and as a discipline for individuals and for groups. This book may represent the beginning of that noble effort.
Don't be put off by the technology Weinberg occasionally uses within the text. At the time of this book's writing, FORTRAN, PL/1, and APL were in common use and OS/360 was the defacto standard. If echoes of the past bother you, ignore them! Instead, concentrate on Weinberg's main topic: the people who develop software systems. For example, consider the following: "...the average programming manager would prefer that a project be estimated at twelve months and take twelve than the same project be estimated at six months and take nine. This is an area where psychological study could be rewarding, but there are indications from other situations that it is not the mean length of estimated time that annoys people, but, rather, the standard deviation in actual time taken." Of course this notion applies as much today as it did then. Weinberg provides numerous, powerful insights throughout the text that have stood the test of time. He got it right then--and it is still right.
The book is well researched and contains many stories. All ring true and some made me laugh out loud. If you don't see a little of yourself in this book, you aren't a computer professional. Buy it, read it, and then leave it on your manager's chair. It will do both of you a world of good.
7 Rereading Weinberg
I bought this book in 1972 (it set me back almost ten bucks!) and read it cover to cover in a single night.
Weinberg spoke to the human situation of programming and as a very young programmer I found the book excellent.
However, I have seen his ideas systematically distorted in practice. The idea of programmer "humility" is all very well: but our society does not reward the humble, and the notion that one must be humble has transformed software developers from the uppity hippies of the early 1970s to a class of neo-monks, laboring to illuminate the sacred texts of a society that is obsessed, not with humility, but with power and control.
As Weinberg was well aware and retails in his book, "structured programming" has a definite mathematical meaning that was proven by two Italians in the 1960s: the result was that you can write any conceivable program using a surprisingly small set of logical patterns.
However, the phrase "structured programming" has in fact been generalized by both programmers and their managers. "That's not structured" means in practice "I don't understand it." It has been inappropriately generalized to apply to programmers and has been used as a term of art by those who would discriminate on the basis of age.
In the artistic arena, deliberate introduction of new paradigms is usually benign. The Dutch artist Piet Mondrian gained great power in his art by limiting himself to what be considered "structured painting", for in his mature style, Mondrian refused to use other than lines at right angles and primary colors.
In the purely scientific arena, parsimony is also benign. Donald Knuth, in commenting on the Dutchman Edsger Dijkstra's advocacy of structured programming, made a fascinating comparision to the intuitionist mathematics of the Dutch Brouwer, which refuses to use the law of excluded middle.
(Who let all these Hollanders in here, one might well ask. While Amsterdam is a byword for freedom among flaming youth in America, Dutch parsimony is a more attractive characteristic. Their national anthem itself (William of Nassau) celebrates William the Silent's refusal to renounce vassal status to the King of Spain, and his stand for ancient feudal rights. The Dutch are an interesting bunch of people.)
But in the political arena, parsimony in particular and the deliberate, forced introduction of a paradigm shift becomes ideology which as Eagleton and Barthes have shown can become myth. The most famous example is Marxism which over a period of about 130 years morphed from science to ideology to Stalinist religion to (perhaps) the scrap heap.
In 1974, as a programmer, I was reminded by the early debates of how to program in structured Cobol of both my art school mates and my political confederates in the late 1960s.
When parsimony and paradigm shifts become commercial methodologies, as did structured programming under Ed Yourdon and others, the open question becomes, is the result benign (as in the minor debates between Mondrian and Theo Van Doesburg, another Dutch artist, over diagonal lines) or closer to Stalinism?
Unfortunately, the latter is true. In somewhat the same way Marx was deliberately misread, the mathematical results of structured programming were used so loosely by data processing apparatchiks that the science became a science of surveillance and control.
8 I was disappointed
I've read dozens of books in this area; I was disappointed with this book. A lot of the material is dated (and I'm not interested in learning PL/1 and JCL). The author has some interesting ideas, but not a lot of hard data (he does have some hard data, just not a lot of it). Peopleware and Mythical Man Month are a better books in this area. This book goes on my give-away list.
9 A hopeful preview
Not quite a review. Hope this isn't too badly out of place.
The original edition of this book is still high on my list of professional references. Though the hardware is dated early in the mainframe era, the personal situations are as true today as they were then. I have cited Weinberg's examples on countless occasions during the past 25 years--the new kid on the programming team who knew better than the plodding old folks, the guy who patched into another part of the code and rewrote it his way because he thought he could do it better than the person who had gotten that part of the job, the value of still having somebody around who remembered what was happening back when the original work was performed, many more ... .
Can't wait to read this new edition!
10 A timeless way to build software
One of the growing movements in software development is the use of patterns. Based on the work of Christopher Alexander as described in his books, A Pattern Language, Oxford University Press, 1977 and The Timeless Way of Building, Oxford University Press, 1979, it entered the computing field with the publication of the classic book Design Patterns by Gamma et. al., Addison-Wesley, 1994. A design pattern is a reusable meta-design that can be applied in many different contexts.
The timeless adjective can also be applied to this book by Weinberg. Originally written in 1971, the only parts that are dated are the descriptions of the hardware. All points dealing with the human elements of software creation are just as valid today as they were twenty five years ago. Furthermore, as long as the human psyche stays as it is, they will continue to be valid. Despite all of our technical and physical advances, there is no reason to believe that human nature has changed in the last three thousand years. As so many writers point out, the high failure rate of software projects is not due to technical factors but human ones. Weinberg deals with many of these points and offers simple advice on how to solve the psychological problems of software development. In many ways, his solutions can be considered patterns as well.
I listed this book as one of the best books of the year in my annual column published in the September, 1999 issue of Journal of Object-Oriented Programming and could probably do so again in an other twenty five years.
11 Condensed, highly quotable software wisdom. 0% redundancy!
What prompted me to buy and read this book was Steve McConnel's recommendation in Code Complete. After reading Psychology from cover to cover, I have become a Weinberg fan!
The book is a true jewel - not deficient, not redundant. Every sentence means a lot, and carries insight and pure wisdom. The book demands your utmost attention. Weinberg speaks with precision, simplicity, grace, and wisdom. I found myself quoting him very often! The anecdotes are memorable and relevant - you'll find yourself narrating them to others!
Things I liked most: The entire section on "Egoless Programming". The first three parts of the book are amazingly relevant, although the book has been written over 25 years back (I didn't even exist back then!)
Things I liked least: The last part "Programming Tools" seems to be the only part that's dated. It may be more meaningful to someoone who has experienced such tools and languages.
Now I look forward to reading Weinberg's other books, including "Becoming a Technical Leader", "The Secrets of Consulting", and the "Quality Software Management" series.
12 Still great after all these years
If you need to inspire creative, independent people to work together, you'll learn a lot from this book. Smart, sensible, and non-obvious desc riptions of what makes a good team.
