Robert Glass’s two postulates (of which he reminds us in “Frequently Forgotten Fundamental Facts about Software Engineering” on the IEEE Computer Society web pages) reflect several important issues. First off, they accommodate the focus on “people issues” in the otherwise technological domain of computer programming. Among other things, this focus has helped the research discipline of empirical software engineering to address the practice of software engineering from additional viewpoints (managerial, sociological, and psychological) to the purely technological one. A necessity, one would say, in order to make the practice of software engineering more evidence-based.

For the purpose of our discussion, let’s assume that the two postulates from Robert Glass hold. Mind you, we’ve made it our business to constantly reevaluate and refine such assertions, even when the assertions may be based on empirical evidence. Knowledge is never static, so Glass’s facts might, in fact, need some refinement. But let’s postpone that. What we are interested in right now are three questions that these facts entail, and which stand on their own accord. They are more general because they consider software development as a whole, and not only programming:

A confirmatory answer to the first two questions would be nothing less than a small revolution, and people like Joel Spolsky would be delighted. He writes that hiring superstar (rather than average) programmers determines whether you produce a truly great product that will bring the world forward or whether you’ll just produce mediocre code that will give the rest of your team a series of redesign, reconstruction, and debugging headaches [Spolsky 2007]. The truth, however, is that it is extremely hard to get hold of top-notch programmers. People long in the business of hiring software professionals have sensible ideas and useful advice as to what to look for (see Spolsky again), but the problem remains hard. In general, finding, keeping, and developing talent is very much in the front of HR managers’ minds, but there is a lack of evidence-based methodology to follow through on this, according to the 2010 Global Assessment Trends Report [Fallaw and Solomonsen 2010].

The third question touches upon the distinction between a focus on capacities in the individual (e.g., skills and personality) and a focus on facilitating the environment (e.g., using tools and putting people together in pairs to program). It probably isn’t sufficient to hire the best programmers, just as it isn’t enough to hire the best pilots for an airline to minimize the risk of air disasters; you also need a lot of safety features in the environment, along with the ability to work with other people.

Striking the optimal balance between human expertise and tools is nontrivial. But if you can’t even determine what an expert is, then you might not have the option to balance anything. Moreover, if you think you know what a good programmer is, and your intuitions are wrong, then your project might be in dire shape, unless it is facilitated by environmental measures designed to detect and adjust for unforeseen contingencies. The operability of Glass’s insights therefore depends on reliably discerning clever people from the crowd. As we’ll see, it’s not at all obvious that you can do that. Software engineering consists of diverse tasks, and the nature of the task at hand influences the degree to which you can determine expertise.

Let’s start by looking at programming.