(Re)Reading the Classics

 

 

I am a product of the 1980’s. Like some (many?) other ACCU members I cut my teeth on the 8-bit and 16-bit home micros that appeared during that decade. After an initial period learning BASIC from the bundled manual I soon realised the only true way to get anything decent out of these machines was to drop down to machine code. A lack of tooling at the time (probably due more to a lack of pocket money than products) meant hand-writing machine code and then poking it into place via a loader written in BASIC. The computer manuals of the time were very functional in nature, not in the paradigm sense of the word, but in the more traditional – they told you what the keywords did and perhaps gave you an example of how to use it. Any nods to Structured Programming were, I suspect, strictly for the professional programmer.

 

I spent seven years messing around with computers at home and school before eventually going to university to study Electronic Systems Engineering. During that time I did both an O’Level and A’Level in “Computer Science”. Despite my ability to program fast, smooth sprite-style animations in machine code, my grades were distinctly average. Apparently “computers” are about more than just programming and so to get a decent grade you need to know a whole load of other stuff about batch processing, punched cards, governance and a host of other dreary topics. The fact that my sister, who knew practically zilch about programming, got an A in both only went to show that Computer Studies (sic), was a pointless waste of time. The only things I remember learning in those classes were the cool tricks from the rich kids whose parents could afford to buy them a BBC Micro. Oh, and Pascal, well, enough of it to do my A-Level project, but it seemed a neat language in a quaint sort of way.

 

As I mentioned recently [1] my decision to study analogue electronics turned out to be an incredibly poor choice. I had far more success with digital electronics because I could just stitch the building blocks together the same way that I would compose functions together in code. The course contained a few options on Software Engineering, which I selected, but to be honest C++ just seemed like a massively bloated extension to C. At least that seemed like a slightly more efficient way to write assembler. We covered Object-Orientation too, but it took watching the lab assistant turn our simple text-based “shapes” C++ assignment into an X Window based version of Asteroids to really grasp the power of some of the concepts. However no one appeared to doing any System Programming in C++, so it all felt quite literally academic.

 

Of course the real education starts when you leave academia, get a job and have to deliver real code to real customers. Fortunately my first job was with a small company that produced PC based desktop publishing software where quality was high on the agenda, even if the magazine reviewers didn’t appreciate it. That meant continuous learning was an established practice brought about, in part, by subscriptions to various publications, such as Dr Dobbs Journal, Windows Developer Journal, Microsoft Systems Journal and C/C++ Users Journal. Certain key books, such as Steve McConnell’s Code Complete and Steve Maguire’s Writing Solid Code became mandatory reading as they tried to deal with the complexity of a codebase that had evolved over many years into different products and changed platforms along the way too.

 

Once I started freelancing I had to replace all that myself. But the necessity allowed me to discover Application Development Advisor where I first encountered the writings of one Kevlin Henney. C++ Report also surfaced on my radar too, just before its demise! At least some of those articles found their way into book form under the guise of C++ Gems. Around the same time Scott Meyers had kicked off the Effective C++ series which led to the style of books where advice was broken down into a number of “items” – most notably the Exceptional C++ series (Herb Sutter) and C++ Common Knowledge (Stephen Dewhurst). They were great books because they started to highlight the difference between a program that was perhaps technically correct, but ultimately not maintainable due to the dark corners of the language that may have been unintentionally exploited.

 

The other two sorts of books I lapped up were the Design Patterns series and the “Haynes Manuals” of systems programming. The former, made famous by the Gang of Four’s Design Patterns, were the two big series: Pattern Orientated Software Design (POSA) and Pattern Languages of Program Design (PLoPD). The latter were the various “Undocumented” and “Internals” books, such as Undocumented Windows (Andrew Schulman) and Windows Internals (Mark Russinovich). I always found myself working on projects where squeezing every last ounce from a box was the norm, despite the relative costs of developer versus hardware suggesting otherwise, and so I’d spent a lot of time learning everything I could about the platform and language I had always worked with.

 

And then in 2007 I joined ACCU [2].

 

Whilst I was clearly comfortable with the mechanics of producing software for my clients, I found myself beginning to question the more “computer science-y” side. For instance I realised that I didn’t really know what the differences were between classes and types, or functions, procedures and methods, or lambdas and closures, or aggregation and composition, etc. I had previously been throwing terms around without really knowing if I was using the correct one. There were also a variety laws and principles, such the Law of Demeter and SOLID that I knew what they stood for, and had an appreciation of what they were getting at but was sure I didn’t fully understand all the forces involved. For example, The Liskov Substitution Principle (the L in SOLID) talks about types and not classes, does that matter?

 

A discussion on the ACCU channel at work led me to ask what the state of the art was in books on OO. I had a copy of Object-Orientated Modelling & Design by James Rumbaugh (1991) that I had rescued from a skip when moving offices around the turn of the millennium, but I had only skim read it. Somewhat to my surprise there wasn’t really anything new. The books of the same era, such as Grady Booch’s Object Orientated Design and Bertrand Meyer’s Object-Orientated Software Construction were still the recommended reading. One slightly newer book (1996) that came out of the same discussion that I posted on accu-general was Arthur J. Riel’s Object-Orientated Design Heuristics. The great thing about old books like these is that they’re ten-a-penny in the online second hand book shops so it’s not going to break the bank to own them all.

 

As I started reading them I also began to look up the references that they were citing, which in turn led me to even older books and published papers. Whilst I was aware that technology had obviously changed rapidly over the years, in contrast, the principles hadn’t. There is always a danger though that those principles can become redundant without you realising it, such as the Law of the Big Three in C++ which has largely become a minor-issue since the invention of the reference-counted smart-pointer. It’s also common for people to recite phrases such as “premature optimisation is the root of all evil” without knowing the context in which it was framed. But do you need to know that, isn’t it just “obvious”? I don’t think so, and I believe it’s the reason Herb Sutter has the item on Premature Pessimization in his C++ Coding Standards book to highlight the effects of just glibly trotting out so called “best practices”.

 

One name that came up frequently (apart from Edsger Dijkstra of course) was David Parnas, the man credited with identifying one of the three pillars of OO – encapsulation. Whilst many papers and articles of that earlier era are locked behind subscription based services I managed to uncover a book with a collection of his papers – Software Fundamentals – and it was going for about five quid. Parnas is a great writer and putting aside the actual content itself, which is gold dust, the style he writes in is worthy of attention alone. I thought I knew what an Abstract Data Type was until I read his paper on them. Also, reading about what is essentially exception handling in a paper dated back to the early 1970’s is a great reminder of how timeless a lot of this stuff can be.

 

You can’t go to an ACCU conference without hearing at least a dozen times about why we should be designing our code to exhibit low coupling and high cohesion. Tony Barrett-Powell went one further in 2010 [3] and did an extensive session all about it and many of the other related principles too. What was noticeable again was that the works he was referencing were the older ones, for example books about Structured Programming. I found out that Meilir Page-Jones covers the subjects of coupling and cohesion pretty extensively in Practical Guide to Structured Systems Design a book initially published in 1980! Kevlin Henney’s more ACCU conference attempt to recast “SOLID” as “FLUID” just goes to show there’s still so much more to unearth.

 

As I suggested earlier you have to be a little careful with what you read in some of these very old books as there is definitely advice that is a little dubious 30 to 40 years on. Whilst the programming side is still possibly valid, it’s more the development process that you may find yourself wincing at. That said, the definitive classic book of software development is probably The Mythical Man Month by Fred Brooks. His No Silver Bullet article must be pretty near the top of most referenced works. For me though The Tar Pit, which is the first chapter, is great way to remind yourself why we get up in the morning to follow our chosen path. Meeting and chatting to Tim Lister at the ACCU conference two years ago instantly elevated his masterpiece Peopleware to the top of my reading pile. And with good reason because understanding the environment we work can have a significant effect on our productivity as well.

 

So, what of the output of modern day authors? Are there any books that I can see others discovering in a decade’s time or that I’ll find myself returning to again and again to see what new insights I can glean? One author that immediately springs to mind is Kent Beck. His books on Extreme Programming, TDD by Example and Implementation Patterns have already become a constant source of reference and more importantly inspiration, with the latter being one of my favourite programming books of all time. Whilst his books are short on pages they are jam packed with goodness and all written in a particularly comforting style.

 

As I become more experienced and therefore more comfortable with being able to make software that “works” I can devote more time to what it means to “make it right”. Once upon a time I wanted books to get inside the heart of the machine or compiler to understand it, now I want books to get inside the head of the experts to understand what they “see” and what makes them better programmers.

 

References

[1] Passionate About Programming or Passionate About Life? – C Vu, July 2013

[2] The Downs and Ups of Being an ACCU Member – C Vu, May 2013

[3] http://accu.org/content/conf2010/accu2010Coupling_TonyBarrettPowell.pdf

 

Chris Oldwood

21 August 2013

 

Bio

Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via gort@cix.co.uk or @chrisoldwood.