author : Robert L. Glass

Glass lays out a series of "55 frequently forgotten fundamental facts" about Software Engineering. Most of these are not so much forgotten as well-known but ignored (such as facts about requirement, estimating, testing, and quality). Others are little known, or are repeatedly forgotten and repeatedly rediscovered, such as the importance of the maintenance part of the life cycle (and that maintenance is mostly not about bug fixing). Others are somewhat contentious (such as the impossibility of generic large-scale code reuse, and the uselessness of much academic software engineering research), but Glass argues that they are indeed facts, and backs up his arguments with data and references (often to his own earlier work bringing these facts to light in the first place). He also lays out some standard fallacies: things many people believe to be facts, but which are actually not true.

His very last item, Fallacy 10, is: "You teach people how to program by showing them how to write programs", that is, as opposed to first learning to read programs. What other languages do you write before you can read? I've occasionally wondered if it would be better at least to start students off modifying programs; it's often a lot easier in a new language to edit a working small program than to start from scratch, because all those annoying little syntax details are there ready for you to copy, as are larger coding patterns. One of my first experiences of this was as a PhD student umpteen years ago, writing what I didn't then know were called shell scripts, in the obscure "Phoenix macro language" for the local IBM 370 mainframe. There was a manual, but reading it was alleged to be a gestalt experience, in that you could only understand it if you already knew it. So everyone (apart from the real gurus) wrote their scripts by modifying other scripts. (I suspect we were degenerating into a restricted pidgin after a while.) I'm even more forcefully reminded of this idea, because I spent half an hour only yesterday modifying a BibTeX .bst file to get my references in the format I wanted. I've never even seen a manual for this language, but I made (most of!) the changes I wanted. And I'm sure if I ever do get around to needing a manual to do something more complicated, it will make much more sense to me after my initial hacking programming efforts. Such an approach is anathema to those who think is would lead to unbreakable bad habits, and that things should instead be taught "properly", but it fits well with other ideas about how people learn in today's high-tech complicated poor-user-interface society, as I have speculated earlier.

So, that last item sparked the most interest for me. On the whole, reading through this book, the main experience is one of rueful recognition. Yes, that's true; and yes, we all know that's true, but no, we all do nothing about it. So what is to be done? Glass gives little help here: his stated aim is merely to make us aware of the facts, not to tell us how what to do about them (except to armour us against the snake-oil, silver bullet, and hype vendors). So, no new solutions, but maybe an indication that we could do so much better even without recourse to silver bullets.