Culture varies a lot between companies, and getting the right cultural fit between employee and employer is a big part of making the relationship a successful and long-lasting one. So why do we so often leave culture until the last stage of the interview, usually in the “so, do you have any questions for us?” phase? Why are we content that organisational culture is so often judged by simple stereotypes: “They are a start-up! They can’t be bureaucratic!”

I suspect one reason is that the people writing the job descriptions and running the interviews lack the skill to effectively communicate about non-technical aspects of the job. Sure, we all know words like “dynamic” and “entrepreneurial”, but these are hackneyed to the point of being useless, like the proverbial “good team player” that every applicant describes themselves as. Another sticking point might be the difficulty of communicating about the culture on behalf of the whole company. I can describe the technical aspects of a role pretty objectively, but in describing the subjective aspects there’s a much higher chance that I’ll say the wrong thing and get myself in trouble.

Another issue, and I suspect a significant one, is that any statement about culture necessarily dissuades some people. This is simple information theory: if a description doesn’t put some people off, then it isn’t conveying any information. Descriptions that appeal to everyone will (unless they are simply and objectively disprovable) be slapped on every job advert. Although companies are usually interested in finding people who are a good fit, in markets where qualified employees are in short supply (as in software at the moment), there’s a great deal of resistance to cutting down the field of prospective candidates in any way.

A better way to go about this might be to identify some qualities for comparison that are deliberately divisive. These would form axes where neither extreme was right or wrong. If we can come up with some kind of de facto standardisation of this, then companies need not lose out by being honest—indeed over the longer term they would lose out more by pretending to be something they aren’t. Eventually, it might reach the point where companies look like they have something to hide if they don’t publish these details.

In Cultures and Organisations: Software for the Mind, Geert Hofstede identifies a number of statistically significant variations between organisation cultures, which I’ll loosely summarise:

• Process-oriented vs. results-oriented: In a process-oriented culture people follow their job description, while in a results-oriented culture they do what’s necessary for the end result. If this sounds like the former is obviously “wrong”, consider safety-critical work where performing to a consistent standard is more desirable than performing better with occasional lapses.
• Employee-oriented vs. job-oriented: In an employee-oriented culture the company takes more interest in an employee’s life outside work, including any personal problems that may affect their work. On the negative side, some people find this overbearing.
• Parochial vs. professional: In the former model, employees identify more strongly with the organisation they are a part of, while in the latter case their strongest identity is with their type of job.
• Open systems vs. closed systems: Open companies are very open to outsiders joining the company, and new people quickly feel “at home”. Closed companies are less open to outsiders, but once people become accepted by the team they can enjoy stronger and more stable relationships.
• Loose control vs. tight control: Looser companies have fewer rules (explicit and implicit) about standard of dress, behaviour etc., and tend to have less punctual meetings and more irreverent talk about the company.
• Pragmatic vs. normative: Pragmatic cultures respond to the needs of the market, while normative cultures tend to follow rules or structures that are viewed as unchangeable.

In my experience, software companies tend to cluster at the same general places on each of these axes, so perhaps these aren’t the ideal ways of judging. Even so, there’s some room for information to be conveyed: just because I like an organisation that’s pragmatic and results-oriented doesn’t mean that I want an organisation that’s jammed right up against the far extremes on these axes. Choosing between a company that’s 60% pragmatic versus one that is 75% pragmatic may feel like small potatoes, but the consequences of employment decisions play out over many years, so I think we can afford to be picky.

Do you see it? In the same block as the requirements for technical skills, they request that you enjoy beer.

It’s pretty clear what’s going on here. It’s not really a job requirement, but they were brainstorming ways to make the company appear cool and sociable and whatever, and this seemed like a fun way to do it. It sets the company apart, because nobody else writes about drinking alcohol on their job description.

Unfortunately, there’s a very good reason for that. I hate to go all knee-jerk politically correct HR on you, but you just can’t do this kind of thing. At a stroke, you’ve ruled out muslims, recovered alcoholics, methodists, pregnant women, people who just don’t like to drink, and all sorts of other classes of people I’ve not thought of here. Sure, it’s only in the “pluses” section. Yes, nearly everybody in this category will understand that it’s just light-hearted fun, and that it won’t really be used to distinguish candidates. That doesn’t matter. You can’t afford to make people of any sort of minority feel unwelcome in your organisation.

Realistically, every company has a non-neutral culture, and for every culture there are going to be some people who feel they don’t fit into that. Completely neutralising this kind of culture is impossible and to a large extent undesirable—the best you can do is to maximise diversity while preserving the positive aspects of what makes your culture unique. But job advertisements are a special sort of communication: they are very public indeed, and they are often the first chance you get to communicate your message to prospective candidates who know nothing else about you. Inviting someone out for a drink after you’ve got to know them is a completely different proposition from broadcasting the desirability of drinking.

My response was probably more sarcastic than it really deserved, especially given that it turned out not to be quite as silly as it sounded: I merely had to change the answer I gave to the question “What is your mother’s maiden name?” It didn’t matter what my answer was so long as I could remember it and produce it on demand.

This situation wrong on several levels. First of all, it’s pretty terrible from a usability perspective. Remembering that I should reply “sausages” when asked for my mother’s maiden name is not particularly hard (at least if only one of my bank accounts suffers from this peculiarity, and I log in often enough that I remember this), but it’s an ugly wart on the user experience and leaves the impression of a bank that is pretty half-arsed.

At a deeper level, this is wrong because it’s symptomatic of poor application architecture. At some point during the software development, somebody must have looked at a database diagram like this:

Somebody else must have known that, under certain circumstances, the security question would have to be changed. Unfortunately, these two people weren’t the same person, and don’t appear to have talked to each other. The architecture clearly doesn’t support the ability to change the security question. Sure, this kind of bug happens all the time—except that security, more than anything else, deserves the kind of architectural attention that’s obviously missing here.

But there’s an even more fundamental reason why this situation is wrong. The bank appears to be confused about the very purpose of using the mother’s maiden name (or any other personal information) as a credential.

Time was when finding out someone’s mother’s maiden name was seriously difficult, unless you happened to know it. Marriage certificates are public record, but (and I’m guessing here) they aren’t indexed in the right way to make it a tractable problem to look up the maiden name from the married name. In the days of paper files, it didn’t matter if something was O(n) provided that n was large.

Nowadays, it no longer works this way. The population of married people is large by human standards, but small enough to be searched in seconds by a computer, even if the search method is inefficient. I don’t know how marriage records are exposed, but it’s reasonable to suppose that a sufficiently motivated attacker can get the data set. Even if not, plenty of people have enough information on their Facebook or LinkedIn profile to infer a mother’s maiden name.

Personal information still has a role to play in security, but not in the same way. People tend to think of password cracking as trying lots of attempts to guess one person’s password, but an alternative is to take one obvious password and try it against a number of people. Money is money, and you don’t care much whose account you rob. For a given common password, a large enough bank is almost certain to have somebody who uses that password.

Against this kind of attack, the trusty old mother’s maiden name comes in handy. If it only takes 2 minutes of snooping on Facebook to find the information you need, then this doesn’t stop you attacking one particular person’s account. But if you want to try ten thousand accounts to find the one whose password is “5au5age5″, then you’re out of luck.

A crucial point here is that this kind of security benefits only marginally by changing the secret answer. By hypothesis, the secret answer is pretty easy to get hold of anyway. The great strength of personal information is that you don’t forget it; if this wasn’t an important part of the design then everyone could just make their password twice as long and get exponentially greater security. But passwords are already pretty much at the limit of what human beings can cope with, and personal information is a low-cost way to extend security against an important class of attacks.

The first thing that occurs to me is that it’s not just start-ups. I can’t remember when I first interviewed a candidate, but it can’t have been more than a year after graduating, and the company I worked for at the time was not a start-up by any means. Then again, I think the whole “start-up” distinction is pretty much a meaningless concept, or at best a loose grouping of organisation culture attributes that have relatively little correlation with size and method of funding.

The suggestion in the article seems to be that engineers apply standards that they themselves wouldn’t meet. I dare say this happens, probably in part due to the need for validation that some engineers suffer from. People who were among the very best in their local environment during childhood and early schooling are over-represented among engineers, and the inevitable process of meeting people who are better than you in later life (not everybody can be the best) presumably leads to a great deal of insecurity.

The Stanford Prison Experiment lends an additional angle to this picture: perhaps the very situation of being given interviewing power warps your judgment of the correct way to use that power. This is certainly something to be aware of and defend against, but personally I haven’t seen any evidence for it. If the effect is real, then it’s a very interesting question whether this is restricted to young and inexperienced interviewers, or whether the same effect acts on more experienced people. One of the more alarming conclusions of the original Stanford experiment was that this was not pathological behaviour but affected ordinary, apparently well-adjusted people.

I’m less worried about what goes on during an interview than I am about whether the end result of the interview is to accept the right candidates. Only very poor interviewers reject all applicants, and interviewers who deliberately reject strong candidates and accept weak candidates are even worse and hopefully very rare. Therefore the main issue is whether the criteria used are a good match for what the organisation needs, and whether there is any form of bias among the good candidates who do get accepted.

Reflecting my own interviewing behaviour, my biggest concern is that I’m too soft on candidates who are similar to me (articulate, broad range of knowledge, smart but not of the very top rank) and too hard on candidates who are different (among whom I’d include domain experts and people with unusually strong academic records). In so far as I suffer from this prejudice, I don’t think it’s limited to the interview room.

To me, the hardest problem seems to be determining the dividing line between fundamental company culture and the personal preferences of the workers. As Tom DeMarco points out (quoting Peter Drucker) in Slack, the whole point of a true company culture is that it doesn’t and shouldn’t change. Hiring against company culture in this narrow sense is counterproductive for all concerned. Hiring people who are a good fit for the culture but against one’s own preferences should enrich the company. Differentiating between these cases deserves careful attention.

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.