The Psychology of Computer Programming

One of the more interesting questions that I get is how to get an organization to adopt agile methods. Sometimes folks frame it in terms of a problem: “I’m trying to get my organization to buy off on agile development, but they’re not convinced.” I believe that the book The Psychology of Computer Programming can really help with making agile development more powerful. Let me explain.

One of the things that I’ve noticed with most of the agile books, articles, postings, and so on, is that they describe WHAT to do and HOW to do it. However, they are noticeably missing the WHY it works. They’ll argue that WHY to do it is that you experience more productivity, efficiency, quality, etc.; however, they rarely attempt to explain WHY those benefits occur.

So how can a book that was written 25 years ago explain how agile works? The answer is simple. Agile works because it capitalizes on the psychology of programming – even if it only capitalizes on it by accident. Penicillin was created by accident, remember. Some of the core reasons why agile practices work are explored with experiments in The Psychology of Computer Programming.

By now you should be asking, “Okay, so how could I use it to help me sell agile to my organization?” The answer has to do with some of the antiquated material in the book and the way that they may seem nostalgic to the managers who are leading the technology department.

The book was originally published in 1971, so its references are, to say the least, a bit dated. The language examples are FORTRAN and PL/1. The most prevalent system mentioned is OS/360. There are references to punched cards and computer rooms. Terminals are just beginning to gain favor. However, despite the quite noticeable and sometimes distracting antiquated references, the core messages about how programmers (developers) work with one another and with the computer are still clear.

Frankly, the references to older systems make the book more credible than the respected agile books of today. Senior technical managers often will remember these systems with a sense of loss that they can no longer develop code. (Everyone’s inner geek suffers when it’s not allowed to grow.) Because of this connection, the more formalized study methods and the slightly academic feel of the writing makes it a book that is believable to anyone who grew up through the technical ranks.

So how do you use this? First, read a copy of The Psychology of Computer Programming, plowing through some of the parts where it seems like there may be little to offer in terms of today’s agile methods. Highlight the sentences and paragraphs that align to today’s agile practices. Then hand it over to the manager who’s not convinced that agile is the way to go and ask him to read it.

You know that they aren’t likely to read it, but they may flip through and notice your highlighting. You’ve got them hooked. If they read around the highlighted passages they’ll find that comfortable nostalgia and, hopefully, settle into trusting the book.

From there, it’s just a matter of hinting that you should try some of the ideas outlined in the book – that just happen to align with one of the agile methods you’re looking at starting.

I have no idea whether the founders of the agile methods that folks are reading today read The Psychology of Computer Programming, but whether they did or not, there are certainly some interesting correlations.