As I said, I am reading Joel Spolsky’s The Best Software Writing I. Actually, I’ve just finished reading it, and I like it. Of the collection of essays that Joel selected for the book, however, there is one that should not be there, in my opinion.
Joel says in the Introduction that he will poke his eyes out with a sharpened pencil if he finds another spirited attack on Microsoft’s buggy code by an enthusiastic nine-year-old trekkie on Slashdot. Well, Paul Graham is no nine-year-old, but his behaviour in Great Hackers, the chapter he contributes to Spolsky’s book, is more or less that of a misinformed kid. I have read Graham’s Hackers & Painters and I liked it, although some chapters run along the same lines as Great Hackers does. Great Hackers, however, is surrounded by high-quality writing, and therefore sticks out like a sore thumb in its propaganda and prejudice.
I am going to dissect Graham’s Great Hackers bit by bit, and counter-argue each section to illustrate my point. Of course, my point is just an opinion, and my opinion is not more valid or superior to anybody else’s, including Graham, although I hope to be more objective and provide more backing to my claims than him. In any case, you draw your own conclusions.
Spolsky’s introduction to the chapter, interestingly enough, gets infected by Graham’s lack of rigour and starts with a sentence that announces what is to come: “There’s no doubt that a software project won’t succeed without the right programming superstars”. Wrong. I have participated in many projects which were successful and did not have a superstar. Actually, most of the projects I have participated in fall into this category. So, at least, there is doubt.
Moving into Graham’s material, he starts by retrieving his argument on variation of wealth that can also be found in Hackers & Painters. His reasoning is like this: variation of wealth in a society is good because it is a sign of variation of productivity, which in turn is good because if we didn’t have differences in productivity among people, that would mean that nobody is Thomas Edison, as opposed to everybody being Thomas Edison. In this line of reasoning, fallacy number one is that variation of wealth is necessarily correlated to variation if productivity. I can think of many examples when this does not happen, royal families (lots of wealth and low productivity) and Mozart (amazing productivity, no wealth) coming to mind. In a non-western society, examples are even easier to find. Fallacy number two resides in the very concept of productivity. Graham does not say what he means by this term. He assumes that not everybody can be highly productive (and therefore we find wealth variations), but I can argue that everybody can be equally highly productive if we agree that productivity can be related to many different realms and not only to the mere economical. For example, Mozart gave the world extraordinarily beautiful music, which is not very productive in terms of money, but it is in terms of cultural enrichment. My wife is not very productive as far as the global economy is concerned, but she gives me something that nobody else can. Is that being productive? Alexander Fleming discovered penicillin by accident, triggering the development of mainstream antibiotics and the end of high worldwide mortality rates by infectious disease, but he didn’t accumulate wealth despite having changed the course of history. Is this being productive? Without a definition of “productivity”, Graham’s claim is just a void statement, since it cannot be contrasted.
Graham also claims that in low-tech societies you don’t see much variation in productivity, and uses an example involving a tribe of nomads collecting sticks for a fire. He argues that the best stick gatherer is not going to be much better than the worst. He even suggests a factor of two, without any empirical backing. In any case, one can think that, precisely in a low-tech society, there is a lot of room for improvement, if we understand improvement as technological development, and therefore I can argue that one of the stick gatherers may stumble against a broken shard of quartzite and start flaking it further in order to develop a stone implement. That would be being productive! In a low-tech society, technological change can be attained with very little, and any small progress is comparatively large. In a highly technological society, on the other hand, further progress usually needs institutional support and significant amounts of time and resources, as the research tradition of the West shows. This clearly contradicts Graham’s thesis.
Then Graham dives into the “more than money” issue, i.e. what other things, apart from money, do excellent programmers want? To start with, he claims that ordinary programmers write code to pay their bills, whereas great hackers (his word for excellent programmers) do it for fun, and are delighted to find out that somebody would pay them for it. Again, he boldly claims it, with no backing or reasoning. And, once again, it clashes with my own experience. I have met excellent programmers who coded for fun, but I also met excellent programmers who didn’t give a damn about programming, and who would retire to their other pleasures as soon as possible (and one actually did it at the age of 31). I have met mediocre programmers who coded to pay the bills, sure, but I have also met mediocre programmers who just love programming, and would keeping doing it for free. Actually, most of them kept doing it at home, in their spare time, just for the sake of it. But they sucked. So, in my experience, no pattern can be established here without rigorous empirical work. Which Graham does not provide.
Then things start to get funny. Out of the blue, Graham states that “…good hackers prefer Python to Java…”. Excuse me? According to which data? Perhaps Graham means “…the good hackers that I happen to know prefer Python to Java…”, but this is not what he says. He makes a sweeping statement with no backing whatsoever, very much like the proverbial nine-year-old trekkie attacks Microsoft’s buggy code on Slashdot. He goes on to say that the programmers that you can hire to work with Java are not as smart as those you can hire to work with Python, and that the “fact” that good programmers prefer Python as opposed to Java tells you something about the merits of those languages. I couldn’t believe it. I was used to Graham’s verbal diarrhoea from reading his book, but this was too much.
The fun continues with “Great hackers also generally insist on using open source software”. Again, he makes this bold sweeping statement without further backing. Well, my own experience contradicts this. In my experience, great hackers generally insist on using the Microsoft .NET platform. I am aware that I work in a given community, which is biased towards certain platforms and technologies, and I am aware that there are other communities out there with their own biases too. I even read about them and befriend some people from these other communities. Because I am aware of this, I don’t write publicly that great hackers prefer .NET; they do in my community, but certainly not in others. Perhaps Graham is not aware that there are other communities in the world, some of them oblivious to open source code, some of others loving Java, some others picking a bit of this and a bit of that. If he is not aware, he should not be writing books. If he is, he is being very unfair and consciously misinforming his readers.
He continues with the old myth of open source, i.e. that it is better because you can change it if you don’t like it. I have already argued this silly belief elsewhere, but I need to rephrase it here. Graham argues that excellent programmers prefer open source because it gives them more control. For example, an excellent programmer developing an application on Linux who finds a bug or issue with the operating system can, technically speaking, modify the operating system to fix the bug or solve the issue to their convenience. Yes, this is technically true. Now, let’s think of the implications. First of all, our friend the excellent programmer is surely working in a real-world project for a real-world customer, not in an ideal world without deadlines and with infinite resources. Therefore, his manager would not be very happy when Mr Excellent Programmer comes and says “look, Morgan, I have found that the single-threaded cache manager that comes with our distribution is not good enough, and I am going to spend <fill in your estimated number of weeks here> weeks writing a new one”. Secondly, Mr Excellent might be a genius developing business applications, but he may well lack the expertise and knowledge to successfully modify a body of code as complex and obscure as an open source operating system. Thirdly, and assuming that Mr Excellent knows how to change the open source operating system, and that his boss has a few weeks of slack in the schedule, the application being developed would be tied to the modified version of the operating system, which would have to be distributed to and installed every single machine where the application needs to run. Not very modular, is it?
In my worldview, Mr Excellent is Mr Excellent, precisely, because he knows that software development is much more than programming. He knows that layering and abstraction are key issues, and when you develop a business application on top of an operating system you don’t mess around with the underlying layers; you just look at them as a black box. My Mr Excellent knows how to focus his attention in the task at hand, and how to create the best solution possible with the given resources. Dreaming of changing the operating system to suit the application needs is fine for the beers after work.
The last story that Graham tells about how hackers’ preferences determine what is universally good and bad is as follows. A friend told him about a start-up company that had chosen Windows NT as an operating system. And Graham, instantly, knew they were doomed, because no decent hacker would work with Windows NT. Honestly, doesn’t this sound like a nine-year-old trekkie? Graham rejoices in explaining how, in fact, the company shut down a few months later. This is a textbook example of the concept of demagogy.
The remaining sections in Great Hackers are not as pathetic as the first ones. The one titled Nasty Little Problems, however, deserves some attention. Graham states that hackers like interesting large problems rather than nasty little ones, because “Working on nasty little problems makes you stupid”. Once again, this contradicts my experience. The best programmer I have ever met had his passion in solving little problems. He never wanted to participate in any large project; only solve pesky little problems, and he did it with an elegance and finesse that I’ve never seen again. So Graham’s sweeping statement is not true.
In summary, I find Graham’s chapter to be hyper-capitalistic, lacking in humanism (despite his often flaunted studies at the Accademia of Florence), and of no objective value whatsoever. As opposed to the other contributors to Spolsky’s book, he seems more interested in shoving his convictions down everybody’s throats than in explaining and educating. Hopefully, I have shown that many of Graham’s bold statements are false by finding counter-examples. I am not trying to say that reality is just opposite to what he says; I am only saying that what he claims to be universally true is not so.
As a final note, Spolsky has compiled a great book, but including Graham’s essay, in my view, was a deplorable decision. Still, I’ll buy The Best Software Writing II whenever it comes out.