Rating: 
Summary: Retrospective on Pioneering Days
Review: 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?
Rating: 
Summary: Silver anniversary edition hits gold
Review: 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.
Rating:
Summary: Good info on collaborations, but short on details and dated
Review: 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.
Rating: 
Summary: An Update to One of the Most Influential Books in Computing
Review: This landmark 1971 classic is reprinted with new commentary and a Preface from the author. Long regarded as one of the first books to pioneer a people-oriented approach to computing, The Psychology of Computer Programming endures as a penetrating analysis of the intelligence, skill, teamwork, and problem-solving power of the computer programmer. Returning to topics that are strikingly relevant to today's issues in programming, Gerald M. Weinberg provides a characteristically fresh perspective on his original insights, highlighting the similarities and differences between now and then. Using a conversational style that invites the reader to join him, Weinberg reunites with some of his most enduring, straight-from-the-heart observations on the human side of software engineering.Dorset House Publishing is proud to make this important text available to new generations of Weinberg fans -- and to encourage readers of the first edition to return to its valuable lessons. Reviews of the Silver Anniversary Edition: "Whether you're part of the generation of the 1960's and 1970's, or part of the current generation of the 1980's and 1990's, you owe it to yourself to pick up a copy of this wonderful book. Once you've digested it, you should then track down all [twelve] of the other Weinberg textbooks published by Dorset House. . . . Every one of them is a jewel."-- Ed Yourdon, Cutter IT E-Mail Advisor "What surprised me as I read it again was how timely Weinberg's questions remain."-- Dwayne Phillips, Editor's Choice Author Comments "On an inspired eight-week vacation in Italy, I wrote the first draft of The Psychology of Computer Programming. . . . the book quickly became a best-seller among technical titles, running through more than twenty printings and staying in print for twenty-five years. . . . For this Silver Anniversary edition, I decided to take my own advice to reviewees and not try to hide my errors, for they would be the source of the most learning for my readers. I decided to leave the original text as it was -- antiques and all -- for your illumination, and simply to add some 'wisdom of hindsight' remarks whenever the spirit moved me. I hope you find the perspective brought by this time-capsule contrast as useful to you as it has been to me."-- GMW From the Epilogue ". . . the reader who has really been touched by this book will start to work on the operating system he carries around in his own central processing unit -- his head. That will be his reward." Partial Contents Introduction to the Silver Anniversary Edition Preface
Suggestions for Course Use
I. PROGRAMMING AS HUMAN PERFORMANCE
1. Reading Programs
2. What Makes a Good Program?
3. How Can We Study Programming?
II. PROGRAMMING AS A SOCIAL ACTIVITY
4. The Programming Group
5. The Programming Team
6. The Programming Project
III. 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
IV. PROGRAMMING TOOLS
11. Programming Languages
12. Some Principles for Programming Language Design
13. Other Programming Tools
V. EPILOGU
Rating: 
Summary: Condensed, highly quotable software wisdom. 0% redundancy!
Review: 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.
|
