July 30th, 2010
Richard Wiseman has a nice retelling of the apples-and-oranges puzzle (which incidentally was a regular interview question at a company I used to work for):
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.
Tags: hiring
Posted in Software Development | No Comments »
July 30th, 2010
As part of my preparations for living in Zambia, I’ve had to have some vaccinations. One of the recommended vaccinations was Hepatitis B. Luckily, the UK National Health Service provides Hep B vaccinations for free. Unluckily, they also provide Hepatitis A vaccinations for free, and the two are delivered as a combined vaccine. I’ve already been vaccinated for Hep A, so I can’t have the combined shot. This means I have to have the single Hep B vaccine, which isn’t free.
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.
Tags: debugging, Zambia
Posted in Business, Software Development | No Comments »
July 27th, 2010
I’ve never been that keen on blogging about personal matters, since it seems like the wrong medium to me: my friends will find out what’s going on in my life when I talk to them, and people who don’t know me have no reason to care. Never the less, I’m undergoing a change in personal circumstances that will partially alter the goal and scope of this blog, so it seems appropriate to report it here.
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.
Tags: Zambia
Posted in Meta | No Comments »
