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
For a book to reach a silver anniversary and still be relevant is either a massive compliment to the book or a damning indictment on the computing industry. In this case, as with Mythical Man Month, it is both.
The book acts as a historic record of how far we have come and allows us to appreciate the changes that have occurred in respect to machine power, tools available, and sexual equality. But it also demonstrates how far we still have to go in terms of getting software development working effectively. We encounter many of the same problems today as are documented in the examples of this book from over 30 years ago. Some of that is hardly surprising given that it is people that develop software; not the machines, the tools or the environment, and people haven't changed as much in 30 years as the environment in which they find themselves.
Weinberg has either been enormously influential or just tremendously precognitive for many of the situations dealt with in this book are part of our standard cannon of techniques and are embodied in the lifecycles and techniques that we have all come to know and love over the years. Is the book then still relevant?
Well, yes, people are still in charge.
Since this book was first written, Gerald Weinberg has written at least 15 more books, many of which expand on the topics in this book, indeed the introduction to this anniversary edition lists those which he feels have expanded most. Some of those later books have used some of the same examples from this book so an avid Weinberg reader will feel instantly familiar with some of illustrative anecdotal episodes.
The question then arises "should I read this one, or a few of the later ones?" I would recommend both. This version of the book has the advantage that the original text remains untouched but there are additional sections that document how the author feels about the text now and provide some reflective wisdom on the proceedings.
Psychology is a difficult topic to pin down although I'm sure there must be a standard definition of it somewhere. I've read that the name itself, from derivation and ancient usage, means "The science of the soul", and in common usage has come to refer to the science of mental life. Encompassing more that its title, this book deals with the psychology of the programming organisation, and that includes programmers, testers, managers and their relationships.
Many of these relationships remain unchanged today despite much writing about the topic in computing books and general management texts. People work best together when they communicate and do not demonise other development roles. Testers should not be seen as the lowest level in the development hierarchy and programmers are more than code production machines.
Programming is approached as both a learning process and a process that can be learned, and techniques for improving the effectiveness of learning are covered. Some of these techniques are common knowledge now; independent verification by other programmers, walkthroughs, reviews, documentation, learning from mistakes, but even though we know how important they are and even though evidence of their efficacy is widely available, they are still not used as often as desirable. Focus is given to the required mental state that has to be adopted to make these techniques work "egoless programming". Gerald Weinberg has expanded on these topics in a variety of his other work.
This is a book that stimulates the reader. The use of anecdotal stories works much like the Ericksonian hypnotist's use of metaphor, without being aware of it the reader will be applying the metaphors to their own situations. Anecdotal stories are used to teach the reader to consider the nature of secondary gain when attempting to effect change in an organisation, and the need to understand existing processes and situations. There is a wealth of knowledge here for anyone involved in Process Improvement.
Testing is mentioned in places throughout the text, mostly relating to the poor social status of testers or the lack of focus on testing itself. But the main section on testing can be found in chapter 13 and there is good advice here that is still being ignored today "to have confidence in the testing or a program, we should want to know to what extent our tests actually covered the coding." Error seeding is cited as a possible technique for improving the test process but there are undoubtedly better ways. Although this chapter is professing to be about tools, there is a lot of good advice on correct design to reduce errors and to help make testing more effective.
Writing tests early is rationalised succinctly as being a way to guard against the overconfidence generated from the early successes of adhoc testing resulting in testing being stopped before adequate coverage has been achieved.
There is much to gain from this book even if the reader is not a programmer, and even if the reader does not know how to program, because its focus is software development staff and the relationships that exist between them.