Worth Reading #1: The People Who Write Software --- Weinberg and Brooks
2064 words • 11 min read • Abstract
This series is a way to acknowledge, and share, what I have read that influenced my approach to software development, and much of that goes beyond coding. I have read many, many books on every aspect of software development; the ones in this series are the ones that stood out and stayed with me. A lot of their ideas are timeless, not tied to a particular fad or fashion in software development.
This first post is about two books on the people who write software.
| Book | Author(s), year |
|---|---|
| The Psychology of Computer Programming | Gerald M. Weinberg, 1971 |
| The Mythical Man-Month | Frederick P. Brooks Jr., 1975 |
| The series | Worth Reading: every post |
| Comments | Discord |
The Psychology of Computer Programming
Gerald M. Weinberg (1971; a silver anniversary edition followed in 1998, but I read the original). Programming as human behavior: programmers working alone and in teams, and egoless programming. All eight of its main ideas stayed with me. In each box, Weinberg’s idea is on top and what it meant for me is below:
Detach from your code, and invite others to find its bugs; the code gets better faster.
At IBM, on a team developing parts of MVS/XA, we embraced it. We had many code reviews a day, with stakeholders from many departments, and the code was discussed in detail.
As a developer, I was expected to take the feedback as valuable and educational, not as personal criticism.
Most programs are written by groups; how a team works matters as much as any one person's skill.
That was a new idea to me. I had thought writing software was all about telling the hardware what to do.
Code is read, maintained, debugged, extended and replaced, by many people, possibly including me, later. It should be written for that wider audience, not just to produce running code.
Read other people's programs the way writers read literature, to learn style and to find problems.
For me it was a daily occurrence, at code reviews of other people's code. Later, open source opened up tons of code to read.
We do not see the errors in work we have just made, so someone else should review and test it.
Writing PL/S for MVS, we stepped through every branch both ways, tracked in yellow highlighter on printed assembler listings, delivered by cart after every compile.
A function tester once accused me of skipping that, when the console showed SEXTENDED TORAGE. My highlighted listing showed exactly where I had stepped through it, oblivious to the insert going in at the wrong offset. I was not the best tester of my own code.
If a program does not have to work, it can meet any other requirement. Fast with the wrong map gets you somewhere sooner, but not where you meant to go.
Releases I worked on went in that order: version 1 "light the lights", an MVP before the name; version 2 "fix the bugs, add the missing features"; version 3 "make it fast", and "make it better", such as usability, often an afterthought.
My new projects go the same way: it works, then features, then faster and easier to use.
Remove the vending machine where programmers gathered, and you lose the hall talk that solved problems.
Most of my working environments encouraged hall talk, and many problems were solved informally: at a whiteboard, over coffee, or at lunch.
Ability varies widely between programmers, and aptitude tests predict little.
The hardest part of software development is dealing with people. When I get pushback, I think of "dogs bark at what they don't understand", and the onus is on me to explain it better.
As an architect, and in technology transfer, I had to tell different audiences different things, for different concerns. It was not straightforward.
Judge a language feature by how people read and write it, not only by what the machine needs.
Now they are for agents too, human and AI. Lisp, Scheme and Clojure were adopted less than I hoped; many could not get past the parentheses. I have my own likes and dislikes, and no language suits everyone.
Like the personal computer, I think the personal programming language is coming. I have created several, among them X_eTaL, sw-MLPL and PL/SW.
The Mythical Man-Month
Frederick P. Brooks Jr. (1975; the 1995 anniversary edition adds No Silver Bullet). Brooks managed the development of IBM’s OS/360, the ancestor of the MVS I later worked on, and the book is what he learned from it. Five of its ideas affected me most; again, Brooks’s idea is on top and what it meant for me is below:
People and months are not interchangeable. In Brooks's words, "The bearing of a child takes nine months, no matter how many women are assigned."
Nine women cannot have a baby in one month, but more than nine, overlapping, can produce babies on a monthly cadence. I have many, many projects, and I cannot finish each one as quickly as I would like, but I can show progress across the board by overlapping the work in parallel, which multiple AI coding agents make possible.
The first system built is a pilot, and you will throw it away anyway; the only question is whether you plan to.
I do plan to throw away early prototypes, though a new language is more often the next step than a replacement. X_eTaL is the next step after sw-MLPL, and sw-MLPL was one too: I worked on ideas before it, like Tuplet, and many of my COR24 languages informed its development.
PL/SW was implemented in C, will soon be in HLASM, and eventually in PL/SW itself.
A designer's second system is the most dangerous one: every feature held back from the first goes into it.
I have to resist the temptation to rewrite complex systems, because a rewrite loses the benefit of many fixes.
Organize a team around one chief programmer, with others in support roles, rather than many equals working on the same code.
It has been a holy grail. At IBM Research I was the lead developer on a team, writing 90% of the code.
Lately, with my teams of AI coding agents, I am the chief programmer again, but at a higher level, writing less code than I have in the past.
Essential complexity belongs to the problem itself; accidental complexity comes from the tools and environment. No technique removes the essential part by an order of magnitude.
That distinction has been a driving concern for me when I design tools, languages and operating systems. sw-checklist leans on it too.
Closing
These early readings influenced my choices for decades, and they are still relevant today, even as some of their ideas evolve: the chief programmer now leads a team of AI agents, and languages are written for agents as well as people.
Part 1 of the Worth Reading series. View all parts
Comments or questions? SW Lab Discord or YouTube @SoftwareWrighter.
