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

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

In short, both the following instances ought to work, but the one in the class method should automatically know to print some extra gubbins about the object:

struct Something {
   void someMethod() {
      LOG("Some logging message");
   }
};
 
void someFunction() {
   LOG("Some other logging message");
}

I thought this was an interesting case, not so much for the eventual solution as for the thought process involved. One of the big problems with C++ is that although you have no shortage of powerful tools that enable metaprogramming, they were never designed to provide a coherent system. It takes a bit of experience even to know what’s possible, let alone how to go about finding a way to do something. With most metaprogramming the pattern is to find one language feature that yields the information you need (perhaps a type trait, a typedef, a function return value or whatever) and abuse some language feature (sizeof, SFINAE, template argument deduction etc.) to allow the original feature to indirectly feed through to generate a usable compile-time value such as an enum or typdef.

Obviously macros are going to be involved here: no other tool in C++ allows for code reuse and gives the repeated code access to the scope in which it is invoked. But macros are purely a lexical concept, so we’ll have to include something else that operates at a syntactic level to discriminate between the cases.

So what’s different in state between member and non-member functions in C++? There’s the this pointer, for a start. Also, a different namespace scope is available and potentially different accessibility to private and protected class members. Other than that, there’s not much else in the ISO standard (compiler extensions like __PRETTY_FUNCTION__ might help, though).

Using the this keyword is the most direct route to the information we need, since it pretty much is the information we need. Unfortunately, the definition of this is such that even mentioning it when outside of object context is an instant compile error. Since we can’t so much as mention it in our macro definition, we’re going to have to be a bit craftier.

The problem is that using this outside of a method is a syntax error, which will kill our compile immediately. Except there’s precisely one case where the compiler can recover from a syntax error and take a different path: instantiating a template. If the compiler attempts a template instantiation and gets a compile error, it may discard that template specialisation and try another possibility. This is surprisingly useful and even gets its own name, the rather snappy Substitution Failure Is Not An Error.

Unfortunately SFINAE isn’t going to help us here, because the area of expanded code where an error is allowable is within a different scope than the place we’re trying to log from: it’s either always in a free function scope, or always in a method scope (depending on whether we use a template function or a template class for SFINAE), but it will never depend on the calling context.

So we’re back to the drawing board, except that we know that we can’t mention this in our macro. This leaves us with two possible ways to discriminate the cases: class member accessibility and function overloads in scope. As an example of the former, consider the following:

#include <iostream>
 
using namespace std;
 
class Something {
public:
	static void func(...) {
		cout << "Ordinary function, anyone can see this" << endl;
	}
 
	void method() {
		Something::func(42);
	}
 
private:
	static void func(int n) {
		cout << "Private function, you need to be privileged" << endl;
	}
};
 
int main(int argc, char ** argv) {
	Something::func(42);
 
	Something something;
	something.method();
}

This is how you might like it to work: the call in main() gets the unprivileged overload, and the call in Something::method() gets the more specific overload that it can only see because it’s in the context of the class. This, by the way, works by a quirk of C++ that varargs functions are always used as a last resort and only if an overload that matches better is not available. Let’s ignore for the moment the fact that this only detects if we’re in a special sort of class (namely the one that defines func(), or a friend of it) and not the general distinction between class and non-class.

Unfortunately, we can’t use accessibility in this way because function overload resolution happens before accessibility is checked. Rather than getting a different result from the overload resolution in each case, you get the same result from overload resolution in each case and a compiler error if the preferred form is not accessible. You may be thinking that SFINAE could save us here, but in fact we have the same problem as before: the call will take place outside of the scope we’re trying to detect.

So the only thing we have left that distinguishes between free function context and method context is the different set of functions in scope:

#define LOG( x ) cout << (getThis() ? "In method" : "In function") \
   << ": " << x << endl;
 
void * getThis() {
   return NULL;
}
 
struct Fish {
   void * getThis() {
      return this;
   }
 
   void method() {
      LOG("Log line");
   }
};
 
void function() {
   LOG("Log line");
}

This is promising, actually. In fact, it’s pretty close to what we want except for the fact that we have to define this log method in every class that we want to be able to log from. This isn’t as bad as it first seems, since the only reason to get hold of the this pointer in practice is to call methods on it, and we can only do that if all the classes implement a common interface anyway.

In practice, the getThis() construction is a little weak. It only returns a void *, and in order to call any methods we’ll have to cast it back to the proper type, and we’re back to the problem of not knowing the type of the class we’re in (or even if we have a class type). Rather than trying to implement reusable code in a macro definition, any code that needs to know about types will have to be in a method that’s implemented for every class we care about, and corresponding stubs at global scope. This is pretty horrible, and will probably render this technique useless.

So in the end we don’t really have a solution, but at least we can be reasonably confident that we’re not missing anything.

Much of the above code doutless contains errors, as I haven’t tested a lot of it. Feel free to write in with corrections.

It wasn’t a club but a computer virus that shut down the Whac-A-Mole and more than 400 other games built by Bob’s Space Racers in Holly Hill. The company traced the problem back to computer programmer Marvin Wimberly.

Faced with a pay cut, police believe Wimberly programmed games to fail, ensuring he would be needed and keep making money.

[...]

Each game, after turning on and off a certain number of times, sometimes 50, sometimes 500, would fail. Wimberly would be paid to fix it, and police reports say, he would insert a new virus with a new countdown.

Of course, the big story here isn’t that the malicious action happened, but that it was discovered and traced back to the allegedly deliberate actions of an employee, and that police have been involved.

My guess would be that this type of thing goes on all the time, and is either not noticed or not taken seriously. I suspect it’s mostly not a deliberate sin of comission but a subtle sin of omission: developers don’t refactor, or don’t document, or don’t upgrade their design to integrate with new components. Quite probably they come up with ostensible reasons why it can’t or shouldn’t be done that are sufficiently convincing.

The irony, of course, is that doing a better job should make you more employable, not less. Even when unemployment was at its peak, the companies I’ve been working with have been terribly short of quality developers.

Here are some of factors that I think contribute to this:

• People end up working in software development who don’t have the necessary interest or aptitude, but carry on with it because giving up would cause them to lose face, or because even a badly-paid software job is better than a great deal of alternatives.
• Management in companies where software is only a small component of the business don’t necessarily understand the software development process, and as a result are overly deferential to the opinions of developers. Furthermore, they overestimate the cost of replacing an incompetent developer with a competent one, and underestimate the long-term benefit.
• Bad developers are rewarded too well, and good developers too poorly. The best developers deliver something like 20 times the benefit of the worst developers, but are lucky to get paid twice as much. This blunts the incentive for a mediocre or poor developer to improve themselves, and encourages those at the bottom end of the scale to hang on rather than move to a different career to which they may be more suited.

template<typename T>
class TypeDecryptor {
public:
    static string getName() {
        return typeid(T).name();
    }
};

Of course, not quite everything in the garden is lovely. This provides an implementation-defined string, which as far as I can see is not even required to be unique for a given type. In point of fact, it’s extremely unlikely an implementation will return a non-unique string since each type has to be mapped to a string for linkage purposes anyway. The problem is that the string isn’t necessarily human-readable.

I think that on reasonable implementations there should be a function available to unmangle this string back into a human-readable type, which means you can potentially make a completely general type decryptor.

Anyway, the most useful section of Deep C Secrets is a section that gives a simple algorithm for understanding a complicated C type declaration. You know the kind of thing:

void (*signal(int sig, void (*func) (int) ) ) (int) ;

The algorithm, by the way, is given in a section that has the delicious title “The Piece of Code that Understandeth all Parsing.” I’d forgotten how funny that book is.

The main problem with this is that it’s a run-time operation, and has to take the type declaration as a string. Parsing it involves a whole bunch of logic that already exists in the compiler, but has to be re-implemented. When I was stumbling through some declarations in C++ Templates: The Complete Guide it dawned on me that maybe C++ can do better.

Understanding any type declaration can be broken down into two parts:

• Knowing where to start
• Knowing which piece to process next

The first of these is often rendered difficult by the fact that there are several identifiers in a typedef, and you have to know which is the one being defined (because this is where you start to parse the type). In an anonymous type, there may be no identifiers at all:

doStuff( static_cast< int (*) ()> foobar );

In this case you start with the *, but it’s not easy to see how to know this in general.

The second difficulty (knowing which piece of the type to handle next) is complicated by the fact that you may need to proceed left-to-right or right-to-left, which depends on precedence rules that most people understand only implicitly, and often only by instinct.

Using the C++ rules for template argument deduction, we can ignore most of these issues. The core idea is to declare a template that takes a single compound type and expresses the type in terms of one or more simpler components. For example, we can write a class that deals with a pointer:

template
class TypeDecryptor {
public:
	static string getName() {
		ostringstream output;
		output << "pointer to "
                      << TypeDecryptor::getName();
		return output.str();
	}
};

What this says is that the getName() method on a TypeDecryptor applied to a pointer type will return the string “pointer to” followed by whatever the type decryptor tells us the pointed-to type should be called. We can do something very similar for const:

template
class TypeDecryptor {
public:
	static string getName() {
		ostringstream output;
		output << "const " << TypeDecryptor::getName();
		return output.str();
	}
};

We’ve already got something useful, because it can deal with all that int const * const * stuff that people sometimes have problems with. OK, so you also need a TypeDecryptor specialisation for each of the fundamental types, which just prints out the type name:

template<>
class TypeDecryptor {
public:
	static string getName() {
		return "int";
	}
};

Annoyingly, I can’t find any way to generalise this, so you need an explicit specialisation for any fundamental or user-defined class type you want to support. It could be streamlined with a macro, of course.

So at this point, our decryptor can do things like this:

cout << TypeDecryptor::getName() << endl;
// Outputs "pointer to const pointer to const int"
 
cout << TypeDecryptor::getName() << endl;
// Outputs "const pointer to const pointer to int"

But this is just getting started. Similar things can be done with function pointers, arrays, references, pointers-to-member, etc. One of the more complex cases is:

template
class TypeDecryptor {
public:
	static string getName() {
		ostringstream output;
		output << "pointer to a member function (on type "
			   << TypeDecryptor::getName()
			   << "), taking one argument of type "
			   << TypeDecryptor::getName()
			   << " and returning "
			   << TypeDecryptor::getName();
		return output.str();
	}
};

This allows us to deal with pointers-to-member-function with one argument. Annoyingly, you need an explicit specialisation for every different number of function arguments there can be (one for zero-argument functions, one for one-argument functions, etc…) and also a different specialisation for pointers to data member from pointers to member functions. This means the number of explicit specialisations gets quite large quite quickly.

On the plus side, you don’t need to know anything about type precedence rules to write this code, nor have to make any decisions about where in the type declaration to start processing. The C++ compiler does all the hard work. Without too much effort I was able to get something that could parse:

char (Person::*)(int (&)[42])

into

pointer to a member function (on type Person), taking one argument of type reference to array (of size 42) of instances of int and returning char

• integral or enumeration type
• pointer to object or pointer to function
• reference to object or reference to function
• pointer to member

If you’ve ever done metaprogramming then you’ll certainly have used integral types as template parameters. And I’ve already come across pointers to member as template parameters in possibly my gnarliest typedef ever, which for the record was something like:

typedef
template< typename T>
boost::variant<T::* int, T::* string, T::* double, T::* bool>
   any_member;

You can use this type to refer to any (modulo ramming enough different types in the variant<> list) member on any type at compile time. I had this rigged up into rather a nice compile-time ORM system, where you could define a type and then declare a static instance of

std::map<string, any_member<T> >

that maps strings to members at compile time. You can then have generic code that pulls data out of a database and then assigns it to instances of a the class. So much of it is done at compile time that it was actually pretty reliable code for something so hairy.

But I digress. The point is, pointers to members act in this context quite a lot like enumerated types: there’s only a finite (usually very small) number of valid values that is obviously determinable at compile time. Even integral types, in the contexts where they are used, are finite and typically small. Pointers to objects, on the other hand, usually don’t exist until run time and can take any one of an effectively infinite range of values at run time.

So the declaration

template< int * Foo >
class Bar {
  public:
    void doStuff() {
        std::cout << *Foo << std::endl;
    }
}

is perfectly legal. But how can it be used? Remember, each specialisation of Bar is not just a different object but a wholly different class. On the face of it, this might seem to allow creation of types at run time, which is obviously impossible.

It turns out that they’ve thought of that. When you try to specialise your template it all goes wrong:

int main( int argc, char ** argv ) {
    int * ptr = new int(42);
    Bar<ptr> myObj;
}

This is rejected by g++ with:

error: 'ptr' is not a valid template argument of type 'int*' because 'ptr' is a variable, not the address of a variable

Full marks to g++ for a good error message here. This immediately prevents the possibility that we can generate an unlimited number of types at run time, since we have only a finite number of variables defined in our program, fixed at compile time. But what about the address of a stack variable? Taking the address of the stack variable doesn’t return a value fixed at compile time, because it depends how deep we are in the stack when we do it:

void confuseTheCompiler() {
    int someVar;
    Bar< &someVar > myObject;
}

Fortunately, they’ve thought of this as well:

error: '& someVar' is not a valid template argument of type 'int*' because 'someVar' does not have external linkage

This is made explicit, as you would expect, in the C++ standard. It’s in 14.3.2 clause 1:

A template-argument for a non-type, non-template template-parameter shall be one of:

• an integral constant-expression of integral or enumeration type; or
• the name of a non-type template-parameter; or
• the address of an object or function with external linkage, including function templates and function
  template-ids but excluding non-static class members, expressed as & id-expression where the & is
  optional if the name refers to a function or array, or if the corresponding template-parameter is a reference;
  or
• a pointer to member expressed as described in 5.3.1

So if we restrict ourselves to variables with external linkage then we’re back to the case where we have a fixed number of possible values at compile time, and everything in the garden is lovely.

I’m not sure if this would ever be useful. I came up with this toy example:

#include <iostream>
#include <string>
 
using namespace std;
 
template< int * foo >
class VariableNamer {
public:
	static string name;
};
 
extern int baz;
 
int baz = 42;
 
template<>
string VariableNamer< &baz >::name = "baz";
 
int main( int argc, char ** argv ) {
	cout << VariableNamer<&baz>::name << endl;
}

It enables you to associate one and only one name with a variable that has external linkage, at compile time. If you forget to assign a name for the variable you’ll get a compile-time error, which I suppose makes it better than having a global

std::map< int *, std::string> variable_names;

I’m sure with a little extra finesse it could be modified to assign a name to any type of variable, not just ints.

Even worse, my password for such low-value sites is a dictionary word. Admittedly it’s a dictionary word chosen at random from the Shorter OED, which gives a theoretical 500,000 possibilities. Even if we suppose I ignored overly short words and didn’t choose entirely at random, the odds of someone guessing it have to be one in 200,000 or longer.

This seems reasonable to me, but plenty of sites aren’t having it. As far as they are concerned, protecting me from the consequences of bad password choice is their problem, not mine, and the way to do that is to ensure that my password has at least one digit in it. Or at least four digits. Or maybe a non-printable character. Or at least 2 capital letters. They don’t seem to be able to make their minds up.

So I just do what everyone else does in these circumstances: I use the same password, and make minimal tweaks to satisfy the algorithm. I capitalise the first letter. Or I add a standard number on the end of it (hey hackers, I’ll tell you this for free: I always use the number 12).

Security is always a tradeoff with usability, and the tradeoff here is terrible. Users will always use one of a tiny number of tricks (appending 123, using l33t-sp3ak, etc.) that make minimal increase to the search space. Hackers aren’t greatly inconvenienced, but the user has to remember exactly what set of requirements they were trying to satisfy when they created their password. Here’s a hint to designers: if I find myself having to think hard about what combination of capitalisation and numbering I used when I signed up, and I don’t really like your site, then I just won’t bother logging in again.

But the really dumb thing is that this is defending against the wrong problem. Passwords aren’t typically compromised by brute-force attacks across a large search space, they’re compromised by being human-understandable and relevant to the person that created them (personal names, dates, etc.) Checking the password against common human names and date formats (e.g. 19xx) would be more effective.

And if you’re worried that the web application you’re writing will be subject to brute-force attacks, then it’s easy to defend: limit the rate of queries to human speeds (no more than 5 incorrect passwords per IP address per day) and use CAPTCHAs. Detect suspicious patterns of activity and take action (block the IP address, warn the user being targetted, whatever). Properly implemented, even brute-forcing a mother’s maiden name or a birthday (requiring just a couple of hundred attempts) becomes an uninviting task, particularly when the reward for success is non-monetary.

So why do programmers do this? It’s like the old joke about the drunk who dropped his keys in a dark street and resolved to look for them under a street lamp since the light was better there. Adding rate-limiting isn’t that hard, but it’s orders of magnitude hader than writing a regexp to ensure the password has two digits in it. Even if this doesn’t solve the problem, it gives the impression that we’re making an effort.

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.

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.