At QCon, Glenn Vanderburg, Michael Feathers and I (there may have been others, as I recall some ESB was involved…) were talking about Mike’s 10 Papers Every Programmer Should Read post (if you haven’t read it, please do so now, I’ll wait. No really, go on.) A lot of programmers aren’t particularly well read, a fact that Mike laments, and we kicked around some theories as to why that is – here’s mine.
Why don’t we look at our past? I believe it has to do with the natural (10 year or so) cycle of language dominance. People who’ve never programmed in language n-1 look at the syntax in a book from, say the early 90s and scoff; they complain that they don’t know that language thus they can’t read the book. I’ve heard more than a few developers dismiss Design Patterns because the code wasn’t in Java, of course Java is starting to wane – a couple of days ago I was researching a book and noticed it had a bunch of negative reviews because the example code was Java!
Many developers are essentially Blub programmers and they can’t imagine life in any other language. Further, they firmly believe that anything that existed before Blub is the modern day equivalent of the Pony Express, antiquated and useless. To some, all the good ideas are new, and we have nothing to learn by studying our past, I suspect many of these people have never seen the mother of all demos (though maybe we have something new to rival that now.) A typical Blub programmer assumes that any book that doesn’t use Blub isn’t worth his time and thus misses out on a wealth of learning. They almost willfully ignore the past which explains some of the reactions to Mike’s post.
I’ve been doing my best to read my way through 10 papers and this afternoon I came to Kent Beck and Ward Cunningham’s A Laboratory For Teaching
Object-Oriented Thinking. Now, many people assume the whole agile software thing is just a few years old but here we see waaaaaaay back in 1989, a reference to YAGNI and a plug for teamwork:
We stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity. Working in teams helps here because a concerned designer can influence team members by suggesting scenarios aimed specifically at suspected weaknesses or omissions.
Great ideas then, a great ideas now. We’re a young industry, one that is further hamstrung by the belief that the language/technology/process du jour is all that plus a bag of chips. We’ve obviously made some huge strides, but in so many ways we’ve barely moved. But for the video quality, Engelbart’s demo could have just as easily been from 1988 or even 1998; sure, we’ve all got a mouse on our desk, but what about that 5 fingered keyboard? Not so much. Heck, every language is just trying to reinvent Lisp, and that’s more than 50 years old! Don’t be afraid of the past, those old guys knew a thing or two. We only hurt ourselves by ignoring the lessons they have to teach us.