Technologists who wish to talk about the big picture can sometimes find themselves in a difficult situation: In order to be taken seriously, they have to express a bold vision of the future. But predictions aren’t made in a vacuum, and the opinions of the twittering classes have gathered enough momentum that it’s dangerous to be seen contradicting them. Criticisms of the social web are terribly vulnerable to the rejoinder that the critic just doesn’t get it.

None of this seems to bother Jaron Lanier, whose 2010 book You Are Not a Gadget is a timely and much-needed analysis of the downsides to the Web 2.0 movement. Lanier, though he has form as a technological pioneer of Virtual Reality, is vulnerable to the claim that he is a hippie throwback who belongs in an earlier age. His dreadlocked appearance, humanistic philosophy and love of obscure musical instruments may seem a poor fit for the brave new world of Facebook and Google, but I believe we ignore his insights at our peril.

The book covers a lot of angles, but the overarching theme is a reaction against cybernetic totalism, the view that computer software can and should become at least as important to the world as humans, at its most extreme reducing us to components that serve a hive mind. The most approachable manifestation of this in today’s world is the way that user-generated content (in the form of blog posts, tweets, images, videos, Wikipedia edits and the like) is stripped of context and personal relevance and digested into a stream of data to be fed through algorithms, ultimately making billions for the “lords of the cloud” with zero return to the humans who produced the content in the first place. Genuine creativity is stifled in favour of endless regurgitation and mash-ups.

There’s a more fundamental point behind his argument, and one that’s more tightly bound to the nature of technology: People have forgotten, or never properly understood in the first place, that this is not the only way technology can be. As a technology evolves, choices are made that are hard to reverse, leading to a sense of inevitability where there oughtn’t to be. People have come to believe that computers are the social web, and that the social web is Facebook, or at least something not too dissimilar. This adds a note of pathos to the argument: it’s one thing to desire the hive mind as your future, quite another to believe that it’s inescapable.

To my mind, closer analysis of the argument about technological lock-in threatens to unseat Lanier’s claim that cybernetic totalism is the cause behind the problems he discusses. Where he sees a Silicon Valley elite who are prepared to sacrifice human values to speed the inevitable singularity, I see merely an unplanned marketplace that has hit upon local maxima in the field of methods to extract money from the web. It seems to me that the problems are economic, not political.

Even if cybernetic totalism is something of a straw man, the book overall remains a cogent critique, raising thought-provoking issues that are rarely seen elsewhere. This is definitely not to be missed.

The lack of the market for books on cryptography might be viewed as surprising. Given that the market can sustain over 200 books about PHP, how has a topic as sexy as cryptography not got more than a dozen or so books? It’s like the world saw Schneier’s Applied Cryptography and figured there wasn’t any point trying.

This isn’t actually that unreasonable. Schneier’s book might be showing its age these days, but trying to keep up with the leading edge of research is a game for mugs and crypto researchers, and neither one is in need of a textbook. The rest of us just need a primer on the principles of cryptography that covers the major protocols and widely-used algorithms without dumbing down, and if that’s what you’re after then Applied Cryptography is still the first and last book that need be on your list.

It does have one major hole, and that’s in the coverage of cryptanalysis. Admittedly, cryptanalysis is even further from the everyday reality of most developers than cryptograpy is: attempting to implement crypto algorithms yourself is risky and requires care, but attempting your own cryptanalysis of any non-trivial algorithm is a pointless exercise best reserved for a really rainy day, or just left to the experts. But I can’t have been the only one who feels very dissatisfied at knowing that something can be done, but not knowing how.

On the face of it, Modern Cryptanalysis is pretty much exactly the book I’ve been looking for all these years. It starts from modest assumptions about background knowledge, but covers real military-grade algorithms. It has good step-by-step tutorials and illustrates it with usable source code in Python. It’s reasonably priced (though certainly not cheap), and picks a good range of topics to get a reasonable overview of the field while still being a manageable length overall.

However, it left me feeling frustrated. A little too much time is spent on toy algorithms that are only of historical interest and are well covered by other books. It then attempts to teach the most basic mathematical background before ploughing into weighty topics in number theory such as factorisation and elliptic curves. In general I feel that the information on public-key systems was too much and too soon in the book: you can’t analyse RSA without postgraduate-level number theory. By the same token, not enough time was spent on symmetric block ciphers for my liking, as to me they strike a nice balance of being a rich topic that doesn’t require too much mathematical background for the casual reader to benefit from it.

Perhaps it was my relatively hurried reading of it, but I didn’t feel the explanations were quite clear enough, particularly in explaining linear and differential cryptanalysis. This was exacerbated by an extremely large number of typos, some of which occurred in mathematical expressions and obscured the meaning of the text.

Despite my reservations, this book actually does the job you most likely require of a book on cryptanalysis, which is to demystify it and give enough of a flavour that you know whether you want to read further. It’s not a classic, but it’s a fair starting point.

“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.

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.

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.

This 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.

Luckily, as well as diagnosing an insidious problem this book provides clear and actionable advice that could be helpful to anyone, whatever their current level of communication skills. The authors blend well-observed general principles with specific examples from professional and personal contexts. They have done particularly well to reduce a potentially confusing topic to a single clear model that is simple enough to comprehend and general enough to be useful.

The scope of the book is both broad and narrow. It’s narrow in that it focuses almost exclusively on a single case: people who have violated an agreement or expectation. However, in a sense this still has great breadth since these situations occur in all walks of life. The examples in the book show how the principles apply equally well in work and at home.

I never feel like I’ve written a fair review unless I’ve picked a few holes in a book, and I’m struggling to do so here. The worst I can say is that this isn’t an instant classic, if for no other reason than its narrow scope. However, I can’t think of anyone who wouldn’t be well advised to give it a read.

I won’t say too much about the physical device itself, which functions very well. The e-paper screen is a pleasure to read from. The slightly reduced contrast means it’s tough in very dim light, but the trade-off of being able to read in bright sunlight is well worth it. The inclusion of a qwerty keyboard is a real marmite feature, but on balance I’m glad it’s there.

What really excites me about the devices is its potential to change the way I read. In the past I’ve left a trail of half-completed books in my wake, as I’ve never had the right one with me. Sooner or later I’d forget where I was in a book or even that I was reading it in the first place. If nothing else, the Kindle works well as a way of centralising my collection and tracking where I am with each one. Could I do the same with a few cheap bookmarks and a large sack to carry the books? Kind of, but the point is that I never did do that.

The built-in mobile phone circuitry that supports “whispernet” (global wireless delivery of books) looks on paper like massive over-engineering, since I purchase books far less frequently than I sit down at a computer. However, it changes the nature of the device from a portable book collection to a portable library, and that starts to feel like something out of a culture novel (the series of science fiction stories set in a high-technology utopia.)

Whispernet really comes into its own for newspapers and magazines, which benefit especially from arriving with you fast and effortlessly, and from old issues not taking up space. At the moment the catalogue of magazines is small and many suffer from the lack of graphics, but there are already some good titles that are very keenly priced. If I could transfer my subscription to The Economist to Kindle I might never read a paper magazine again.

One of the most overlooked things about newspaper and magazine delivery is its potential as a monetisation platform. Because it’s linked to your Amazon account, you can pay large or small amounts for content with ease. It may seem odd to say that I like having to pay for content, but he who pays the piper calls the tune. If I want something, I’d rather pay for it than hope that some advertiser values my eyeballs highly enough to pay for it on my behalf.

Using an electronic format essentially kills the second-hand market: since data doesn’t get worn out like a paper book does, resale of e-books by customers would compete unacceptably with new sales. Therefore Amazon has no choice but to prevent resale from happening. I don’t have a problem with this, provided that publishers recognise it and price their books accordingly. Second-hand sale of a book (whether for money or swapping in an informal economy) helps to defray the high cost of acquiring new books (at least part of which is in printing cost, and cross-subsidising printing of unsuccessful books).

In this sense, a Kindle book is less valuable than a brand-new hardback, since it has zero resale value. In the case of back-catalogue books it is also competing against virtually free copies of the dead-tree version from charity shops or Amazon Marketplace, which further lowers the price I’m prepared to pay. I suspect that the publishers who realise this and price accordingly will benefit.

One last thing about copyright: I don’t like the Digital Rights Management (DRM) of the Kindle. DRM is the technology that binds a copy of a book to a particular physical device, preventing you from lending the book to a friend or using it on an e-book reader not made by Amazon. It’s not unduly restrictive in everyday use, but the prospect of buying my entire collection again if Sony wins the format war is a bit of a downer.

However, I think the best way to ensure DRM goes away is to back up my voice with my wallet. DRM on music is on its way out, and this is not because of the people who forcibly broke DRM, but because the iTunes store proved that there was a market of people who were prepared to pay money and play by the rules. Adhering to the spirit of copyright when safeguards were in place gave the industry confidence in a way that arguing over the letter of the law never did.

The first thing to know about SQL and Relational Theory is that it’s largely a retread of Chris Date’s previous excellent book Database in Depth. The latter is a favourite of mine: extremely readable, yet with enough theoretical clout to change the way I looked at databases forever. The new volume carries over large chunks of the text from the older one, with some minor tweaks. As the name suggests, it brings in substantial additional material to link relational theory in with SQL, the only practical implementation of the model in current use.

In the preface, Date explains that the motivation for the new book was the realisation that practitioners weren’t able to figure out for themselves how to apply his theoretical ideas within SQL. Clearing up this difficulty is an admirable goal, and illustrates well that Date’s approach is practical and not meant as ivory-tower theory, but I can’t help but wonder if one of the reasons he didn’t state was that books sell better with ‘SQL’ in the title.

The additional material has resulted in a book that is roughly twice as long. This isn’t a problem in itself, though it does spoil one of the things I loved about “In Depth”: that it could be read in a couple of evening’s work by a sufficiently motivated person. The importance of making a book light enough that you can sit and read it on the sofa without looking like a database nerd should not be understated.

The prose remains clear and readable, and strikes a nice balance that makes it approachable to relative beginners while avoiding ever sounding patronising. Date’s style is precise to a fault, and some people will find it needlessly pedantic; nevertheless, there isn’t any pointless pedantry here, and if you stick with it you’ll learn why subtle distinctions need to be made.

So how useful are the new insertions on SQL? I find it difficult to tell. On the one hand, it makes it much easier to relate the ideas in this book to discussions of theory that actually occur in the real world, since SQL is the lingua franca. In the old book, it was certainly annoying to have all the examples written in Tutorial D, without a real specification of how the language works. On the other hand, Date’s examples in this book are still in a mythical beast called “Standard SQL”, of which no practical implementation exists. What is good practice in standard SQL might be impossible in your chosen implementation, or there might be a better way to achieve the same thing.

It’s certainly worth buying one of the two books here, but the choice of which is not as obvious. If you already own “In Depth”, the updated version probably isn’t worth buying. If you don’t, then “SQL and Relational Theory” is the thing to buy, unless you’re after a lighter and more portable read.

When I came across two books recently that try to make the subject more fun and approachable, I was initially quite sceptical. In my opinion, the main problem with statistics is not that people don’t spend time trying to learn it, but rather that they don’t properly comprehend the underlying principles. Too often teachers seem to be trying to make it more approachable by leaving out the mathematics, leaving just a series of “black box” techniques into which the student plugs the numbers. The problem with this is that it’s easy to plug numbers into the wrong black box.

The Manga Guide to Statistics tells the story of Rui, a young girl who takes a course on statistics in order to impress an attractive teacher. The reader learns through Rui’s eyes as we observe a series of lessons. Though Rui lacks interest in the topic, she seems intelligent and the teacher strikes a good tone that avoids ever being patronising. The characters make for an entertaining read, and unlike “Head First”, the jokes actually made me laugh.

Of course, all this is for naught if the book doesn’t teach the concepts of statistics. Thankfully (and somewhat surprisingly to me), the answer is that it teaches the topic rather well. The main downside to the manga style is that information density is very low, and plenty of technical details are sketched or glossed over entirely. One positive side to this is that omitting details makes the principles stand out more clearly. This certainly won’t be your only book on statistics, but as an introduction it’s an engaging and memorable one.

Engaging and memorable are two adjectives that ought to apply to “Head First” as well, but I’m less convinced by this one. It strikes a chatty, informal tone with plenty of simplified examples, diagrams and other visual aids. A key part of its approach is to express the same idea several times in different forms, the effect of which varies between useful and infuriating depending on whether you were having trouble with the concept. Unlike other Head First titles, I found the tone positively patronising at times.

One obvious difference from the Manga Guide is the sheer volume of information presented. It goes into a lot more depth on graphing, probability and combinatorics, among other things. The pages are somewhat more information-dense, but even so it runs to a massive 677 pages (roughly equivalent to Schneier’s Applied Cryptography, if that gives you any idea). In terms of topics covered you won’t be left wanting, though the format doesn’t make a good reference book.

If you’ve learned statistics before and just need a refresher, the Manga Guide makes a good change of pace even if (or perhaps especially if) you wouldn’t normally read manga. I could certainly recommend the Head First book if you have struggled with learning statistics in other books and want to take things slowly, and if you don’t like the idea of switching to a “real” textbook once you’ve finished with the introductory material.

Secondly, I worry that the books don’t really form introductions to a subject at all, but rather “bluffer’s guides”, that are the first and last book a person picks up on the subjct. To pick one subject I’m reasonably familiar with, I have a long-standing suspicion that teaching mathematics to a casual audience is worse than useless. Even when the reader is an active student of the subject, these books can be used to bypass study rather than to inspire it (at least according to anecdotal evidence from my fellow students).

Happily, neither of these concerns is a significant problem for Medical Ethics: A Very Short Introduction. The author allows his opinions to show through, but is admirably even-handed, even generous in setting out contrasting views.

As regards being an introduction to the subject, this book fulfils its remit very effectively. The area covered is broad enough, and the background information great enough, that the book does little more than scratch the surface on important topics such as euthanasia, genetics and mental health. The necessary background in logic and philosophical rigor isn’t neglected either, with a brief section cleverly slipped in once the reader’s appetite has been whetted by a few philosophical conundrums.

I have very little to criticise about this book. It did feel terribly constrained in what it covered, and stylistically it felt like a longer book cut short to fit the publisher’s requirements rather than a perfectly-turned short book. No sooner had I started to get interested in a topic than the chapter ended—but then of course this is exactly what an introduction should be.