January Reading


Somewhat of a history theme this month. I spent several weeks at the end of December and the start of January driving around Pays Cathare, and with my interest suitably piqued, I sought out some reading for a more detailed background. The first, part of the Osprey Fortress series, was an interesting introduction, and would probably have been better to read before my trips, but The Perfect Heresy was much more engaging. (Update: The Pope Who Quit turned out to be an eerily prescient read!)

Fiction (Series):

The Steve Winslow series was a quick fun read. The books are heavily modelled after Perry Mason, so after trying another series by the same author (and not really liking it so much), I decided to read my way through the original Mason books instead. After loving Lawrence Block’s Bernie Rhodenbarr and Evan Tanner series, I’ve moved on to the Matthew Scudder books. These are much darker, and I’ll probably keep going with the series, but I’m not in as much of a hurry as I was with the two lighter series. The Sigma Force books are a slightly-more-intelligent-and-better-written-than-Dan-Brown scientists-with-guns conspiracy-theory-ahoy rompfest. They’re a little over-long at the start, but the pacing gets better as the series progresses.

Fiction (Non-Series):

Jammy Dodger is a fun tale of ’80s Belfast that likely wouldn’t be quite so appealing to those who didn’t live through it. It’s slightly difficult to know whether Essays In Love should be in the Fiction or Non-Fiction category. Like most of de Botton’s books it’s full of interesting insights and quotable phrases, but is rather patchy. Not the End of the World is a fascinating re-telling of the Noah’s Ark myth that asks a lot of usually-ignored questions of the story. I suspect The Brothers Lionheart would have received five stars had I read it when I was much younger. The Man Who Wouldn’t Stand Up starts off well, but then completely loses it.

Abandoned unfinished:

Not yet finished:

Total: ~9,589 pages


How can we study programming?

When you don’t know very much about a subject, you don’t know in advance what to measure. So your early experiments are not what they might seem to be—they are not to measure things, but to determine what can be measured and what can be worth measuring. The difference here is well exemplified by the difference between the methodologists of anthropology and sociology. The sociologist is working in his own culture, about which he assumes that he is sufficiently knowledgeable to construct, say, a questionnaire as a measuring instrument. But the anthropologist cannot use a questionnaire because he does not know what questions will be meaningful in another culture. Roughly, then, we might say that the sociologist is looking for answers, and the anthropologist is looking for questions.

The social science that provides us with the most useful overall model for computer programming is anthropology. With a little artistic license and stretching of the imagination, we could imagine computer programmers as having a culture—a shared set of beliefs and activities which shape their day-to-day activities. In our study of programming, we shall first examine the “social structure” of that culture— the way programmers relate to one another and to other people who are not programmers. We shall find some surprising possibilities for improvement in this area over present practices, more even than in the second area of study—programming as an individual activity.

– Gerald Weinberg, The Psychology of Computer Programming, Chapter 3


What makes a good program?

No doubt there are programs that are used once and then thrown away. No doubt there are even more programs that should be thrown away before ever being used. Nonetheless, the great majority of programs that are written, especially by professional programmers, remain in existence for a definite life span. And during that span, most of them become modified.

Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why, then, when we are forced to modify programs do we find it such a Herculean task that we often decide to throw them away and start over? Reading programs gives us some insight, for we rarely find a program that contains any evidence of having been written with an eye to subsequent modification. But this is only a symptom, not a disease. Why, we should ask, do programmers, who know full well that programs will inevitably be modified, write programs with no thought to such modifications? Why, indeed, do their programs sometimes look as if they had been devilishly contrived to resist modification—protected like the Pharaoh’s tomb against all intruders?

– — Gerald Weinberg, The Psychology of Computer Programming, Chapter 2

Answers on a postcard, please!


Reading Programs

A young novelist of our time was recently asked who were this favorite authors. He responded simply that he never read novels, as his ideas were so new and superior to anyone else’s that reading would only be a waste of his time. As you might expect, his work did not support his thesis. Perhaps the same could be said for some of our radical young programmers. Perhaps there is something to be gained from reading other people’s programs—if only the amusement engendered by their bad examples. Perhaps if we want to understand how programmers program—to lift the veil of the programming mystique—we could fruitfully begin by seeing what is to be learned from the reading of programs.

– Gerald Weinberg, The Psychology of Computer Programming, Chapter 1

The meme that programming is a write-only skill is one that recurs from time to time. With relatively little software these days needing to be highly optimised, and developer time orders of magnitude more expensive than hardware, the dictum that software should be written primarily for humans to understand, and only secondarily for machines, is truer than ever. The context, and examples, in this book are rather quaint and almost humorous now (like noting that now that programmers actually work at a terminal they can just see what code does rather than having to read it offline).

But there is a great psychological point raised here too that I’ve never heard anyone talk about before and still holds as true today. Often in a software project, things are implemented in a clumsy, awkward, or otherwise non-standard manner. A lot of time this is because the programmer was unaware of the better way to do things, or needed to get on to working on other things as soon as the code “worked”, without having time to tidy it up. But sometimes there was as a good reason for the approach at the time it was written that is no longer true now (to work a limitation in a library being used that has long since been fixed, for example). If it’s in a relatively stable area of the codebase, it can languish there in that form for many years, until one day, needing to make a change nearby, a junior programmer will come in, see what to them is a needlessly complex part of code and congratulate themselves for knowing more than the programmer who originally wrote this nonsense. It’s not unusual, however, for that other programmer to now be their boss, and subtly contribute to building an unhealthy relationship there.


Computer Programming as a Human Activity

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. There are, by various estimates, hundreds of thousands of programmers working today. Each of them could be functioning more efficiently, with greater satisfaction, if he and his manager would only learn to look upon the programmer as a human being, rather than another one of the machines.

At the moment, programming—sophisticated as it may be from an engineering or mathematic point of view—is so crude psychologically that even the tiniest insights should help immeasurably.

– Gerald Weinberg, The Psychology of Computer Programming, Preface

This book was originally published in 1971. A decade ago there was a “Silver Anniversary Edition” published with additional commentary by the author from a perspective of 25 years on, but I don’t have that version; here I’m working from the original text.

There are very few computing-related books that are still relevant almost 40 years on. Hardware and software have changed beyond recognition multiple times, with the steady drive of Moore’s Law leading to computers that are a hundred million times more powerful. Many of today’s young programmers can barely conceive of a time before Google was the first port of call when something went wrong, never mind when computer time itself was so expensive that you had to do all your programming on paper, and, when you were ready, give it to an operator who would load it in for you and let you know the result! At the time this book was written, the debate was still raging over whether the new fangled approach of letting programmers actually work directly at the computer led them to grow lazy and adopt careless and inefficient work habits.

However, although the technical references in this book are often so dated they’re almost unintelligible, the observations on the human side of programming are still scarily accurate. Update the code snippets from FORTRAN to Ruby and the casual reader wouldn’t even realise for large chunks of the book that it wasn’t written last year. The reviews of the Silver Anniversary Edition seem almost to think this is a good thing, as it means the book is still relevant. To me it’s a hugely scary thing. How can we have learned so little in forty years? We should be looking back in horror at how programming was managed then, and the stories should sound as archaic as the technology.

In many ways, then, this book was a failure. The psychological aspects of programming are still poorly understood. Weinberg himself has developed many of the ideas much further in later works (such as the excellent Quality Software Management series), but these are even less widely read. But that doesn’t mean it should be abandoned. It’s every bit as important now as it was then, and the underlying promise quoted above still holds true: “even the tiniest insights should help immeasurably”.


Nothing Happens Until a Sale is Made

Thomas Watson Sr. was one of the extraordinary people in business history. The company he created – IBM – is testimony to his exceptional capabilities as an entrepreneur, visionary, and manager.

Interestingly, when people think of the creation of IBM, and the global behemoth it became, their thoughts turn first to the company’s technological prowess. Although technology is certainly important to the IBM story, it was not really the most critical driver of the company’s growth under Watson’s tenure. The great man himself recognized that when he made the remarkable (for its insight and simplicity) observation – stated in a number of ways to IBMers – that nothing happens until someone sells something

— Mark Stevens, Your Marketing Sucks, Chapter 2


Why Most Marketing Sucks

There are seven key reasons marketing sucks at far too many companies:

  1. They don’t really know what marketing is, but in Kafkaesque fashion, they are going to spend money on it
  2. They go by generalities, even though every situation is different
  3. They do not employ a swarming offense, hitting everyone everywhere they turn
  4. They launch expensive programs and campaigns that are devoid of innovative thinking
  5. They ignore readily available research that would allow them to pinpoint ideal prospects
  6. Corporate management allows the drivers of the marketing process to remain unaccountable for generating a measurable return on the investment that it take to produce the marketing programs
  7. Managers refuse to admit that the only meaningful return on investment is measured by the recruitment of new customers and/or the sale of additional products to existing customers.

– Mark Stevens, Your Marketing Sucks, Chapter 1


What is Programming?

by Tony in * one-offs

What does a programmer do besides talk in programming language? Most programmers would have trouble explaining what they do. Programming is a job filled with details, and keeping track of those details requires focus. Hours drift by and the code appears. You look up and there are all of those statements. If you don’t think carefully, you might think that programming is just typing statements in a programming language. You would be wrong, of course, but you wouldn’t be able to tell by looking around the programming section of the bookstore.

— Ward Cunningham, Foreward, The Pragmatic Programmer


Growing Software

by Tony in * one-offs

Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run. even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit. it should be fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began using this Technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen even if it is only a rectangle. One always has, at every stage in the process, a working system.

I find that teams can grow much more complex entities in four months than they can build.

– Fred Books, No Silver Bullet


Managing Change

I used to think it was because I’m in a classic low-tech industry, but I spend a lot more time sorting out internal problems than I do coming up with ways to incorporate the latest wrinkle in envelope folding. Most managers do not manage change. Change takes them by surprise. What we’re actually managing is the conflict wrought by change. When we hold budget meetings at our company, every department has the same request: We can bury those hotshots across town if you just give us more resources. But before you can beat the guys on the other team, you need to have your own people on board. Good managers have to sort out the conflicts. You can’t just allocate resource and set policy by the numbers. Otherwise you wouldn’t need a manager – an accountant could run the company.

– Harvey Mackay, Beware The Naked Man Who Offers You His Shirt, Lesson 25