Saying that Android is going to lose the tablet wars isn’t exactly sticking my neck out. I’d like to defend a bolder claim, however: Android would lose if the tablet wars were restarted today, without Apple’s massive entrenched lead in apps, marketing and mindshare. The makers of Android tablets scored a catastrophic own-goal by waiting to see whether the iPad would be successful before committing themselves to making competing products. Implicit in all the Android apologist’s reviews of new Android tablets is the idea that Apple’s head start is the reason they’re more successful, and that Android has merely to catch up lost ground (a bit of battery life here, an optimised UI there) and it’ll once again be a level playing field. The Apple fans rightly mock this as grading on a curve, and yet it might be justified if the apologists were right that Android will inevitably catch up. Unfortunately, they’re wrong.

Apple make their devices differently. They have full control over the OS and the hardware, and design them from very early on in the product cycle to work together. Apple deliberately aims at a subset of the market, and eschews features that this market segment doesn’t want. They have mastered the art of taking features out of a product.

Tablets are not just bigger phones or smaller laptops, they are used entirely differently. Tables are consumption devices much more than they are creation devices. They excel in cases where a keyboard isn’t needed or gets in the way, but at the price of losing flexibility. People aren’t using tablets for web development. They aren’t doing serious photo manipulation. Or non-trivial data analysis.

It seems to me that the aspects in which tablets excel are exactly the aspects in which Apple excels. People who want tablets want a streamlined convenient experience, and are prepared to compromise on features in order to get it. Plenty of people exist who want more out of their mobile computing device than this, but they aren’t buying Android tablets (and they’re definitely not buying those clip-on-keyboard hybrid abomninations): they just aren’t buying tablets at all.

It seems to me that this whole argument has a persistent technology myth baked into it: that since technology B arrived later than technology A, it is a suitable direct replacement for it. Tablet computers required a lot more technological progress to get right than laptops did, but that doesn’t mean that they will replace laptops like Homo Sapiens replaced Neanderthal man. TV has yet to stamp out radio, because the latter allows you to do things (like driving a car or cooking dinner) that the former doesn’t. Voice calling never “replaced” SMS (which in fact flourished long after voice calling), just as video calling shows no signs of making a dent on voice calling. The vast majority of content on the web is still text and not video (or audio), since video is not a better text.

New technologies are less disruptive than this, and in a different sense more disruptive. Less disruptive in the sense that the old market doesn’t go away or even change that greatly, but more so in the sense that you often need a whole different approach to succeed in the new market. Right now Apple is the only company that has what it takes to take full advantage of the tablet market, and if any rival does appear I doubt it will be based on Android.

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.

Normal service ought now to have been resumed.

The thing is, there never was a currency crash. There was a security breach at Mt Gox, one of the largest Bitcoin trading houses, which had dire consequences for their customers. But the journalists who wanted to analyse the impact on the Bitcoin market didn’t get any further than tracking the prices at Mt Gox, the very exchange that had just been cracked, and in the process mistook a bank run for a sovereign default. Limiting their view to this, it looked like the Bitcoin economy was in ruins. Looking beyond the Mt Gox exchange even briefly would have shown the rest of the economy was largely unaffected. Retailers continued retailing, exchanges continued exchanging, and coins that weren’t in your Mt Gox account were as safe as they ever were. If you considered Bitcoin to be a reasonable medium of exchange on the 18th of June, there was no reason to change your mind (though double-checking your encryption and backups wouldn’t be a bad idea).

There seems to be one sensible message to take away from the Mt Gox crash: the cyber-criminals have arrived. If Bitcoin ever was lucky enough to fly below the criminal radar, it certainly no longer is. Optimists will probably say that this moment was inevitable, and may even validate how seriously it’s being taken.

Bitcoin has very real, very interesting economic and usability difficulties that probably mean it will never be a viable currency. Suggesting that the recent security flaws in a single exchange undermine it is just lazy journalism.

“[Rails] gained a lot of its focus and appeal because I didn’t try to please people who didn’t share
my problems.” — David Heinemeier Hansson

I always used to maintain that Ruby on Rails was a blight on the world of software development that wasn’t just making individual sites worse, it was making developers worse. Yet here I am a few years on, having chosen to develop my new web application in Ruby on Rails. What gives?

Some of my criticisms still hold up. Rails still encourages beginners to think of every single data-storage requirement as a nail waiting for the hammer of active record. It’s still too easy to write code that doesn’t scale. Above all, while the tutorials are blissfully easy it can still be a hard slog learning what’s going on under the hood, so that you can do more than just cut and paste tutorial code. I believe Rails has improved on each one of these points, but not yet enough for my liking.

Yet I was wrong about Rails, and part of the reason I was wrong goes back to a truth I’ve always held to be under-appreciated: when you choose a technology, you inevitably choose a community at the same time. The Rails community may border on the smug from time to time, but it also seems to have an above-average number of developers who are smart and get things done. Developers who aren’t just happy to do things the same old flawed way, but want to find a better way, and make it work for people. Above all, they deliver solutions that work now, not promising-but-currently-flawed solutions. This was typified by my serendipitous discovery of Timecop, a library that makes testing of time-sensitive code about as easy and effective as it could possibly be. Any language could solve that problem, but in Rails I have a solution right now, with no fuss (yes, I’m sure this particular example is solved in lots of other web frameworks too).

None of this is about the language per se. Rails isn’t better than Zend Framework because Ruby is better than PHP (it is, but the differences come up surprisingly rarely). Rails is better than Zend Framework because Rails has a complete suite of solutions for DB schema management, functional testing, unit testing etc., while Zend Framework plays catch-up. As far as I’ve seen, PHP has nothing to touch Heroku for ease of deployment.

Web development certainly has different challenges from all other development environments. I used to worry that statelessness was a major problem, and I felt that continuation-based frameworks like Seaside and UnCommon Web held the most promise for resolving this. I was wrong, to the extent that while state is consistently a problem there’s a “good enough” solution in the form of MVC, while streamlined automated functional testing of web apps (which Rails does admirably with a test suite based on CSS selectors) brings massive benefit right here and now, rather than in a utopian future.

In my case, the big pause in posts has gone on for two months now. In fact, I’ve been busy with another project, which ironically is a time management tool. I don’t intend to let this blog lapse entirely, but right at the moment I’d rather do one side-project well than two badly.

If you’re interested, please head on over to TaskMaster and let me know what you think, either here or at the feedback forum. It’s at an early stage, and is at least a week or two away from being ready for ordinary users (there’s very little documentation at the moment, so it’s probably not obvious how to use it). I’ll update here and on the TaskMaster blog when there’s some significant progress.

fan•boy |ˈfanˌboi|

noun

1. informal derogatory: a term used to describe people who bought a product that competes with the one you bought, which is probably more popular than your choice, for reasons that you wish to discredit or diminish because you’re secretly afraid or upset that you made the wrong choice.

ORIGIN from fan + boy.

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 bill, the Government Shutdown Prevention Act, declares that the House’s budget proposal (HR1) will become law if the Senate does not pass a budget to fund the federal government for the rest of the year before April 6th. House leadership seemed to have inadvertently ignored the fact that the phrase “become law” contains the concepts “has been passed by the House” and “has been passed by the Senate”. The implication of the measure’s language was that the Senate would pass the House’s budget if it did not pass a budget, or that if the Senate did not pass a budget then the Senate would have passed the House’s budget.

I’ve been saying this for some time: Writing complex rulesets is hard, if they are to be followed rigorously. It’s much harder than most people think. Programmers aren’t necessarily as much better at this kind of stuff as they’d like to think, but they do have the advantage of quick unambiguous feedback, which builds scar tissue. Mostly what experienced programmers know that others don’t is the importance of being circumspect.

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