Software Fallacies

I just finished Robert Glass's "Facts and Fallacies of Software Engineering. I enjoyed most of the facts; many of them resonated with my (admittedly limited) experiences in software engineering. I enjoyed the fallacies too, although I have to admit that I was having more fun when he was skewering other people's pet theories, and less fun when he got to mine.

Glass's Fallacy 10 is "You teach people how to program by showing them how to write programs." This, according to Glass, is wrong. "Big time." Although Glass makes this point with vehemence, he also makes it with no data and an argument that doesn't hold water.

There is no data because, as Glass laments, no one has ever tried the approach he is recommending. A few people have suggested it, and one got as far as writing a textbook, but no one has done the obvious experiment: get two classes, teach one the traditional way, teach the other Glass's way, and compare outcomes. Many of Glass's other facts and fallacies are supported by data, so I was surprised that he was willing to state this one so strongly without any.

The only argument Glass offers is an analogy with natural language, "The problem is this: In learning any other language, the first thing we do is learn to read it [his emphasis]." Well, an analogy is just an analogy, and an analogy is a weak argument because there is always another analogy that proves the opposite claim. Here's mine: you don't learn to play piano by listening to Mozart. You learn to play by playing.

The other problem with Glass's analogy is that it is just not true that we learn languages by reading. When we learn our first language, we learn to understand it first and speak it second; reading is a distant third. In fact, by the time we learn to read, we already know the language. We are only learning how it is denoted.

Glass's analogy is also inapt because while our brains are hard-wired with special modules for natural language acquisition, they are conspicuously maladapted for programming. At least, that's the impression I get when students see recursion for the first time. Most of them can understand it eventually, but for the vast majority it sure doesn't come naturally.

Glass cites several sources to support his non-argument, but it is not clear that even they agree with him. He quotes Bill Gates saying, "the best way to prepare [to be a programmer] is to write programs and to study great programs that other people have written." Um, yes. In that order, I think.

The other articles he cites argue that reading code is important, but none of them claim that it has to come first.

Look, reading code is great. Every programming book in the world has examples, and some books teach primarily by example, or by "dissection". Even the professors that Glass likes to mock usually provide homework solutions that are meant to demonstrate a good design, or good style, or both. But most of the time, it is simply impossible for beginning programmers to read anything like professional code. Beginners start with a very small subset of the language; real-world examples aren't likely to be limited to that subset.

I would suggest that Glass remove this fallacy from the next edition of the book, but that would break his rule of fives, so I feel an obligation to propose this replacement:

Fallacy 10: Software engineers know how to teach programming.

Good programmers are not necessarily good teachers. Many professional programmers are people that took to programming naturally and without effort, and they often have a blind spot for the pitfalls that tend to snare beginners. Also, many programmers are self-taught, which often means that they don't have a vocabulary for talking about programming concepts and techniques.

For most people, learning to program is hard, and as a corollary, teaching programming is hard. I have put a lot of effort into thinking about and improving the way I teach, but I still see too many students struggling, and too many that fail. The only way I know to improve things is to get into the classroom, experiment, see what works, and see what doesn't. I don't believe that experience as a software engineer sheds much light on effective pedagogy.

Appendix

Tarzan, in the story by Edgar Rice Burroughs, is an orphan who is raised from infancy by a gorilla tribe, without contact with humans, until he finds his parents' cabin and the books they left behind. Burroughs explains, "Of course he had never before seen print, or ever had spoken with any living thing which had the remotest idea that such a thing as a written language existed, nor ever had he seen anyone reading.

"So what wonder that the little boy was quite at a loss to guess the meaning of these strange figures [letters]."

But a few chapters later, Tarzan returns to the cabin and begins a dedicated program of study:

And so he progressed very, very slowly, for it was a hard and laborious task which he had set himself without knowing it--a task which might seem to you or me impossible--learning to read without having the slightest knowledge of letters or written language, or the faintest idea that such things existed.

He did not accomplish it in a day, or in a week, or in a month, or in a year; but slowly, very slowly, he learned after he had grasped the possibilities which lay in those little bugs, so that by the time he was fifteen he knew the various combinations of letters which stood for every pictured figure in the little primer and in one or two of the picture books.

Yes, Mr. Burroughs, it does seem impossible, "to read without having the slightest knowledge of letters or written language, or the faintest idea that such things existed," and for a good reason. Because it is impossible.