I’m not so sure. On the surface, video certainly appears to offer the same content that text does, and do it in a more engaging way. However, difficult as it may be to admit for a technologist, I believe video gives with one hand and takes away with the other.

Consider the way you read a text with intellectually challenging content.  You can speed up, slow down, re-play and pause effortlessly and elegantly compared to the effort of doing the same with a video player. Re-playing an idea on a video player isn’t just inelegant, it’s so inelegant that I imagine it’s almost never done, even when the consumer would benefit from considering the idea again. Indeed, far from making it easy to go back, video pushes relentlessly forward, force-feeding the next sentence with utter disregard as to whether you are finished with the last.

Some may retort that this argument smacks of intellectual elitism, and that video content makes material accessible to the less educated. I wonder whether such people are confusing functional illiteracy (mercifully rare, even if not rare enough) with learned helplessness. Facility with reading develops with practice, and suggesting that reading is too tough for large proportions of the population is defeatism. I’m not even sure if it’s true in the narrowest sense that it’s easier for people to understand video than text (though it may be easier to consume without understanding): I can read a newspaper in French with some success, but give me the same news report in video form and I’m quickly drowned in unfamiliar language.

It’s not just on the consumption side. Composing a text is (to me at least) a calm, intellectual and rewarding process, where care can be taken over structure and thoughts can be put down, picked up and re-polished until they represent the absolute limit of the author’s capabilities. No matter how video recording and editing technology improves, a video blog post still needs to be recorded in one or at most a small number of takes, and considerable effort must go just into making the delivery flow naturally, at the expense of actual content. I’ve paused several times during the writing of this post to re-think, even though I started writing with a fairly clear idea of what I wanted to say.

I’m not naive enough to suppose for a moment that these arguments, even if correct, will slow the adoption of video in place of text. In the end, we choose what to consume more with our instinct than with our intellect. I’d be happier if a few more people displayed evidence of understanding the down side, though.

Despite the arrival of fibre connections to the outside world in recent months, satellite is still the most cost-effective means of getting ISP traffic across the border. This is mostly because satellite bandwidth can be purchased in simplex, while buying fibre bandwidth involves paying for a massively under-utilised outbound connection. Obviously the satellite connection boosts the latency, so there’s a lot of trouble doing QoS so that customers who need the latency guarantees get routed to fibre.

The fact that satellite bandwidth is competetive at all should immediately tell you that bandwidth is a significant cost to the business. The economics of selling to a market of relatively poor people don’t stack if you have to buy relatively expensive bandwidth to serve them at a ratio of anything like 1:1. Caching and mirroring would seem to help, but it isn’t 1997 any more: most of what people do on the web isn’t static. You can’t cache Facebook. Even seemingly static pages often have enough dynamic content that you can’t reliably cache them. Mirroring the likes of Google search and YouTube might help, but you can’t get far without negotiating with the big boys, and they may not have time for such a small market.

Traffic shaping is another major opportunity to save bandwidth. No matter how unpopular the idea might be with Californian Slashdotters, in these circumstances the only alternative to an ISP that attempts to prioritise email over bittorrent at peak times is an ISP that goes bust and provides no service at all.

Judged by this standard, Zambia fares quite well. The land is flat, dry, and under-developed, but it has a genuineness about it that immediately appeals. When I last came a few years ago, the most striking sight was of people walking alongside the road carrying sacks on their heads. It seemed to me that there were fewer of them this time round, and more people transporting goods by bicycle.

Apparently a cyclist transporting 4 large sacks of charcoal might earn 10,000 kwacha for a day’s effort in the hot sun. That would just about buy a sliced loaf in the supermarket we frequent.

The problem started when we got to the bag drop desk (having “checked in” online, whatever that means, the previous night). It turns out that British Airways attempt to enforce entry visa requirements at the home end of the journey, and won’t let anyone on the plane who doesn’t meet visa requirements. This makes sense, since it’s a waste of time and jet fuel to take someone halfway round the world just to find that they can’t enter the country.

Unfortunately BA don’t apply the Zambian visa rules, they apply their approximation of the Zambian visa rules, and it turns out we’re an edge case. In particular, in BA’s version of things you can’t go unless you have a return flight booked within 90 days. This makes no sense at all in practice, since we were travelling on a business visa, and could only get a 30-day initial allowance anyway (to be extended later). In BA’s version of events, travelling on a 30-day visa with an 89-day return date is OK, while using the same visa with a 110-day return date is forbidden.

This seems like another case of bugs in real world rules to me. The BA staff at Heathrow had clear instructions, which they followed to the letter. They were courteous and understanding, but the fault didn’t lie with them. The rules are, to stretch an analogy, written to ROM. In the end, we did what any programmer would recognise as a workaround: changed our return flight to an earlier date, flew, then changed it back.

Which brings me to my related complaint: what exactly was the point of “checking in” online the night before if it didn’t ensure we were cleared to fly? As far as I can tell, online checkin consists of nothing more than allocating your seat number and asking security questions, which get asked again anyway. The seat number is sometimes changed later at the whim of the airline as well. In terms of seat allocation, it’s turned an orderly process of arriving at the airport early to ensure you get your preferred seat into a competition to see who can get to an internet terminal closest (to the second) to 24 hours before the flight is scheduled. I was delayed 20 minutes because BA’s mobile web site was either broken or just not implemented, by which time half the plane was already full. What exactly does this online bun-fight achieve?

But enough of the whingeing. We made it here on schedule, and we’re settled into our new house. It’s much harder to pity yourself when you see the conditions many Zambians live in, but that’s a topic for another post.

In the never-ending quest to get page views, the choices writers and editors are making to attract eyeballs and drive traffic are creating a new breed of low-brow, gimmicky disposable content.  At its best it adds little insight and at its worst amounts to a slimy bait-and-switch (catchy headline, nothing to say in the article).

It’s the new clutter. The article itself has devolved into a flashing, animated pile of fluff. The casualty of the rat race towards ad impressions isn’t just crappy layout and thoughtless art direction. It’s awful and useless content.

To me, this seems to be an all but inevitable result of attempting to fund the majority of the web publishing economy with advertising, which in turn is a natural outcome of the post-2000-goldrush exuberance that in the future, everything will be FREE.

The problem with advertising is that a casual or dissatisfied eyeball pays off just as well as an engaged, satisfied eyeball—quite possibly the former pays better, since a dissatisfied mind is more likely to wander away from the content looking for gewgaws to purchase. People (and companies) respond to this incentive, and attempt to gain maximal payoff with minimal effort.

Compare the open web with the content in Amazon’s e-book store (or any paid-content service): sure, there are plenty of bad books, but the vast majority are honest attempts to provide something of value, even if the author’s skill is found wanting.

Curiously enough, it’s not the lack of income that causes this: in places where advertising isn’t possible (e.g. wikipedia, feedbooks etc.) the average quality of content is higher. What seems to be important is not the size of the incentive, but the direction in which it pushes.

Yesterday I saw a drinks machine that had three selections – Tea, Coffee or Random (Tea or Coffee).  However, the machine was wired up wrongly so that each button does not give what it claims. If each drink costs 50p, what is the minimum that you have to put into the machine to work out which button gives which selection?

What I like about this is that it makes more natural several of the constraints of the original puzzle (a crate of apples, a crate of oranges, and a mixed crate):

• Why can’t I just peer into the crate and look at the contents?
• Why only draw one fruit at a time?
• Why do I care how many fruits I have to sample?

It also makes more sense of the effectively-unlimited supply of fruit that is implied by the question: if it’s the wiring that’s at fault and not the hopper of tea / coffee, you could refill it as many times as you want without affecting the wiring.

The puzzle, of course, hinges on the listener not paying attention to the crucial fact: the wiring for each button (or the labelling on each crate) is known to be wrong, not just unknown. It’s one of the neat things about this puzzle that an intelligent solver may well mishear it, but can easily prove it’s impossible if the wiring is entirely unknown. In point of fact, it’s a fairly simple to show that if it is possible, then the answer must be one: we can’t necessarily distinguish a random stream from a constant stream with any number of samples. Constructing a proof that one sample will suffice is fairly easy, given that there are only three possibilities of which to sample, and by symmetricity only two possibilities that differ.

Does this make a good interview question for a software developer? I’m not at all convinced it does. It feels like a meta-puzzle: you reason through it by knowing the implicit rules of the game of puzzle-writing (one obvious one being that the answer can’t be impossible, and it can’t rely on luck or “good enough” solutions like 1000 random samples). Good software engineering often involves judgment calls where such rules don’t exist, and great software engineering often involves rethinking the rules of the game entirely.

It seems odd that having immunity to a disease should drive up my costs for getting vaccinated for another disease. It seems downright bizarre that my making it easier (or at least, no harder) for the government to deliver the free service should mean I have to pay. It would be fashionable at this point to rail against the fundamental inefficiency of government-provided healthcare.

But I don’t think that’s what’s happening here. The mistake the NHS seem to be making here looks like the same sort of mistake that is made every day by thousands of software developers. The set of rules for Hepatitis has a bug in it (no pun intended).

It seems to me that in this case the bug is a leaky abstraction. The obvious goal is to provide immunity to both diseases, and a policy of providing a combined vaccine looks from a high level as if it fulfils that goal. When the details of the policy are implemented, an obvious refinement is not to provide a combined vaccine to someone who’s already had one shot (whether this is a matter of health or cost-saving I don’t know, but it doesn’t affect the argument).

Obviously this is an over-simplification; looking at the world through the eyes of a programmer, things naturally form into shapes and idioms that are common currency to the techie. But I think this there’s something to be gained from seeing the world this way. When people try and build rule sets, they get things wrong. Not because they are stupid, or unwilling, or corrupted, or bureaucratic, but simply because creating perfect rule sets isn’t something that humans are naturally capable of.

As of a month from now, I’ll be moving to Zambia where I will be living and working for at least three months. I’ll be working in a technical role for a local ISP. On the surface my job description may not be all that different, but I expect the culture and business environment to be a radical departure from the UK.

The main difference to this blog is that I intend to post more about the experiences of preparing for and living abroad, in the hope that some of this will be of interest to others. People who were expecting a blog on technical topics (something I never stuck to particularly well) may be inconvenienced by this. I had thought about starting a separate blog, but for such a short-term period it hardly seems worth it.

The punch line? Bob’s email hadn’t been working all morning, and nothing I sent had got through to him. Bob’s emails read to me as if he’d got my instructions and somehow failed to follow them correctly, so it looked to me like he was being inept. From Bob’s point of view, I was giving him stony silence that could only be explained by a lack of motivation.

I’m sure this kind of problem has been plaguing the interactions between technical and non-technical people for as long as there has been technology to bicker over. Users complain about bugs that don’t get fixed, while techies whinge that the users misdescribe their problems, foul things up further with misguided attempts to fix them and then fail to follow instructions when they get them. Why isn’t it going away as people get more tech-savvy?

Behaving correctly when you encounter a fault and reporting it in a productive way is a reasonably subtle task; Simon Tatham’s piece on how to report bugs effectively is a very approachable and effective guide, but it’ll probably only ever be read by the motivated. Even so, you might think that sheer trial and error would teach people that certain ways of reporting a bug get the solution they’re after more quickly than others.

Some people suggest that we techies are lacking in communication skills, and that we need to work harder at making ourselves understood in order to engage with the modern workplace. This isn’t entirely without merit, but I think it’s facile. I’ve been lucky enough to work with some very articulate developers, and none have been immune to this kind of misunderstanding.

I think there’s something deeper going on here, and I think it lies in psychology. The fundamental attribution error is the observed effect that people tend to attribute other people’s behaviour disproportionately to their character, neglecting the possibility of simple situational explanations. For example, I attributed Bob’s inability to solve his problem to his not taking the time to read my instructions properly, or being too poorly-skilled to put them into operation. All the time I was building up in my head a picture of Bob as an incompetent, over-confident bumbling oaf who shouldn’t be trusted to go near a keyboard—and all because his email wasn’t working.

But it goes the other way too. I’ve no doubt Bob had painted a picture to himself of me as an uncommunicative nerd who didn’t appreciate the importance of Bob’s project to the business. Neither of us even considered that there might be an alternative explanation.

The thinking that leads to the fundamental attribution error makes some sense, when you think about it. When you’re dealing with someone on a casual basis you can come to great harm by not making an assessment of their character, and assuming that any flaws you observe are likely to hurt you again in the future is a sound defensive position. This might lead to missed opportunities in casual acquaintances, but that could be a price worth paying.

This thinking is catastrophic, though, when it becomes an entrenched pattern that prevents the very nature of the problem from being properly understood. Blaming developers for being aloof, or users for being incompetent, only reinforces the stereotypes. Working on our communication skills only helps if the thoughts we communicate are based on the right model.