Category Archives: Reviews

Book review: Knowledge for Action: A Guide to Overcoming Barriers to Organizational Change

“The Human Side of Software Development” may just be a tacky slogan I came up with on the spur of the moment to make my WordPress install just a tad less generic, but the sentiment behind it is genuine, and something that I’ve always meant to expand more on in this blog. So here goes, with a review of a decidedly non-technical book.

One thing I’ve been convinced of since I first read Peopleware is that human factors are the cause of more of the problems in the average software team than technical issues. It’s not just that human problems exist in our teams and are difficult to solve, it’s that we don’t learn from our mistakes. Dev never talks to marketing. Engineers blame the testers, and testers blame engineers. Management write off all techies as being difficult to manage. These tropes are played out again and again in thousands of teams, and we still don’t seem to have a really clear idea what the underlying problem is, let alone what to do about it.

Nor is this just a matter of individual learning. Teams and whole organisations need to learn from their mistakes so that we don’t end up pulling in different directions, or even worse have the lone people who feel they have solutions feeling powerless to influence the herd.

Enter Chris Argyris, Professor Emeritus at Harvard Business School, who has spent a lifetime researching topics like these. His book Knowledge for Action attempts to tackle one of the most crucial barriers to this sort of organisation learning, namely the defensive habits and routines that make it impossible for organisations to change. Argyris paints an all-too-familiar picture of an organisation where everyone is overtly committed to effecting some change, but politics creeps in, fights break out and people tacitly cooperate in undermining their own efforts.

Argyris’s main contention is that attempting to change organisations throws up situations of embarrassment or threat, and that people respond to this by avoiding the difficult issues. Moreover, people silently collaborate on this because it’s in nobody’s interest to uncover the threatening material. The case study that’s central to the book develops the author’s hypothesis that by changing our fundamental internal model of the world (taking the focus off winning / losing and onto objectively verifying our beliefs about others) our individual and team behaviour will naturally follow.

I suspect that two aspects of this book will appeal to those of a technical persuasion. First of all, the book is research-based and as precise in its analysis as the subject matter allows. This is not some faddy airport self-help guide for middle managers. Secondly, the approach is the quintessentially nerdy technique of looking to change the second derivative of the problem: not dealing with things that are bad, or even with how to make them better, but how to improve the ‘making better’ process. Hopefully engineers will intuitively see the potential for huge leverage in getting this right.

Unfortunately, I can give this only a qualified recommendation for readers from a technical background. Yes it’s a good book, and a great contribution to the growing body of knowledge, but ultimately it’s still a piece of social science research and the author is clearly intending it to be read by other academics with a similar background. I probably read more “soft” science research papers than the average techie and I found it pretty hard going at times.

So this is really one for the enthusiasts, or those who’ve already read The Fifth Discipline and want to take it further.

Book review: Being Geek: The software developer’s career handbook

Cover of "Being Geek: The software developer's career handbook"
I was excited when I discovered this book. I’ve not explored the topic as fully as I intended in this blog, but I think career issues in software development represent lots of missed opportunities.

The career arc of a software developer is nowhere near as clear-cut as, say, an accountant or a surgeon. Picking your way through a career involves strategic insight that many developers don’t find comes naturally to them. At the same time, many developers seem reluctant to discuss their career aspirations in forthright terms; I suspect insecurity and an unwillingness to appear materialistic play a part here.

So I came to the book with high expectations, and I’m afraid to say I was disappointed. It’s a readable enough book, and the Michael Lopp (or at least his alter ego, Rands) has an opinionated, in-your-face style that is never boring balanced with enough neutrality that his arguments are worth taking seriously. He’s also got credibility on both the business side and the geek side. I particularly liked his elegant summing up of what it is to be a geek:

We seek definition to understand

the system so that we can discern

the rules so that we

know what to do next so that

we win

For all that, the book still feels too much like a series of blog posts sewn together. The chapters are short and the approach to the topic in hand tangential, and far too often they fall into the “five types of …” trope that works so well on twitter and relatively poorly in an printed book. There’s a “how to understand your nerd” section supposed to be addressed to the reader’s life partner, but it was sufficiently stereotypical that I wasn’t sure how seriously to take it.

My biggest problem with the book is that I feel that Lopp has some serious experience to impart, but has taken the wrong approach to getting it across. A particularly obvious example is the repeated attempts to classify the people you’ll encounter in a given situation (say a job interview) into a number of cutely-named categories, with advice on how to deal with the person once you’ve categorised them. This just didn’t work for me because although that may well be how I think about something, receiving such a list from another person isn’t the way I learn.

Geeks may like to boil a complex system down into simple rules, but they want to arrive at the rules themselves, not be spoon-fed. I feel sorry for anyone who’s sitting in a job interview trying to remember Lopp’s categories of people and consequent advice. It’s like trying to ride a bike by solving Newton’s laws: you just have too much else to think about.

What could have been the most useful part of the book also fell short: the issue of deciding whether to work for an established company or a start-up, and whether to follow a management or technical track. In my opinion these are the two most important questions for a developer to tackle, because it’s hard to tell a priori how either choice will pan out for you. To me, Lopp’s approach to these questions felt simplistic and rather one-sided. His image of start-ups seemed idealised, at least compared to my experience on the other side of the Atlantic. The idea that a start-up might fail not with a bang, but with a whimper (and a career dead-end) doesn’t seem to occur to him.

I’ve run out of space to talk about some of the things I did enjoy about the book, and despite the negative tone there were actually quite a few. There are plenty of nuggets of good advice, e.g. on making presentations and time management. The software career book I’m dreaming of has still to be written, but in the mean time this book is well worth the time for any developer who takes their career seriously.

Is the rockstar programmer dead?

What is it with technology? We can put men on the moon, but we can’t create an airport baggage system that doesn’t foul up. Or a word processor that doesn’t crash. Or a web application with a consistent user interface.

One explanation could be that there are actually two sources of difficulty in most human endeavours: necessary difficulties, where a task is at the limit of or beyond a person’s capability, and accidental difficulties, where a task is perfectly achievable but we are open to simple human errors. Though the progress of technology, training and specialisation has raised the absolute limits of what is achievable in most disciplines, human error remains stubbornly as a fact of life and little has been done to ameliorate it.

Front cover of The Checklist ManifestoThis is an idea that is explored at length in The Checklist Manifesto. The author, Atul Gawande, is a surgeon who became suspicious of the number of failures that were happening in surgery that are attributable to human error, often at the cost of grievous injury and death. It would be funny if it wasn’t tragic, that no amount of training (and surgeons are extraordinarily well-trained) is enough to stop a surgeon cutting off the wrong limb, or forgetting to administer vital drugs.

Gawande pioneered a remarkably simple solution to this in the form of a pre-surgery checklist. The evidence is that this reduces complications by double-digit percentages. The main problem in implementing it seems to be in persuading alpha-male surgeons to admit that they are fallible, and that something as simple as a 30-second checklist can make a difference.

It’s not just surgery either. Gawande gives examples of checklists being successfully applied to contain human error in other fields such as finance and, of course, air flight. As a software developer, the following commentary caught my eye:

Tom Wolfe’s The Right Stuff tells the story of our first astronauts and charts the demise of the maverick, Chuck Yeager test pilot culture of the 1950s. It was a culture defined by how unbelievably dangerous the job was. Test pilots strapped themselves into machines of barely controlled power and complexity, and a quarter of them were killed on the job. The pilots had to have focus, daring, wits, and an ability to improvise—the right stuff. But as knowledge of how to control the risks of flying accumulated—as checklists and flight simulators became more prevalent and sophisticated—the danger diminished, values of safety and conscientiousness prevailed, and the rock star status of the test pilots was gone.

As a discipline, software is remarkable for the speed at which it has developed from being on the bleeding edge of research to being an integrated part of our lives, and this is something that the well-worn analogies between software engineering and civil engineering inevitably fail to model.  I’ve often wondered whether this rapid growth, and the small number of generations between the bleeding edge and the current state of the art have distorted our view of what good software engineering should be. This is an idea explored in more detail, and specifically about software, in The Inmates are Running the Asylum, a book I encourage all developers to read.

So, how applicable are the solutions in The Checklist Manifesto to software development? That’s where it gets difficult. Much as I’d like to see the discipline mature, the opportunities for checklists per se are small. There are certainly opportunities to ensure best practices in things like code reviews, merging to release branches or building installers. But ideally any purely repetitive task should be automated anyway, and this covers a lot of ground: software development differs from surgery in that while surgery only looks repetitive, software behaviour genuinely is deterministic. Automated tests, continuous integration and 1-click installer builds are probably the closest thing we have to the surgery checklist, and they are already best practices (though like the surgery checklist, often ignored by alpha males who think they know better).

I’m going to continue investigating the checklist idea and see whether I can integrate any of the spirit of it into my work; I’ll update here if I have any noteworthy progress. But it would be remiss of me not to emphasise one very important point: this isn’t about taking away the creativity of the job, it’s about minimising the cognitive load of routine tasks so that tasks requiring creativity and judgment can be given more effort, not less. There is an art to writing a good checklist, and much of it is in minimising the checklist to give it maximum impact with minimal weight.

If software engineering could become more like flying, perhaps it would be no bad thing. Being a pilot is still a highly technical job that requires great experience and commands great respect. The skill of the pilot is indispensible when something unexpected happens, but that doesn’t mean they carry out routine takeoffs and landings by the seat of their pants.

http://www.amazon.co.uk/gp/product/1846683130?ie=UTF8&tag=reviewtfm-21&linkCode=as2&camp=1634&creative=19450&creativeASIN=1846683130″>The Checklist Manifesto: How To Get Things Right</a><img src=”http://www.assoc-amazon.co.uk/e/ir?t=reviewtfm-21&l=as2&o=2&a=1846683130