Quotes and aphorisms are often used to emphasise a point. Chris Oldwood shares some of his favourites and considers their origins.
One of the benefits of living on a small island (Great Britain) is that you have plenty of old fashioned nautical terms to draw on when discussing matters of software development. For example, I’ve contributed a short segment to the Early Career’s Day at the ACCU Conference in recent years and you can probably imagine my joy at realising I’d be talking about quality in software development in Bristol – home of the expression ‘shipshape and Bristol fashion’ – which naturally I adopted as my title.
One of my other nautical favourites that I’m accused of saying far too regularly (and causes my children to roll their eyes) is ‘don’t spoil the ship for a ha’p’orth of tar’. (The word ha’p’orth is a contraction of halfpennyworth.) Sadly, this gets more airing than I’d like because the quality conversation can tend occasionally towards cutting corners instead of taking that little bit of extra time to refactor more deeply or add test cases to cover the error scenarios.
There are of course plenty of nautical terms which are still in common use by normal people too and I’m not averse to ‘showing someone the ropes’ or ‘trying a different tack’, although I don’t think I could ever bring myself to ‘on-board’ someone (it’s a phrase I’d happily give a wide berth to). Interestingly, the not too uncommon expression ‘a rising tide lifts all boats’, which I find particularly useful when trying express the importance of team members sharing their time and knowledge for the greater good, is believed to be a fairly modern invention.
What I like about many of these old-fashioned terms is that they add a little colour to what can be a somewhat abstract but nonetheless contentious topic. While the phrase ‘best practice’ gets tossed around a lot, it’s debatable whether any are truly ‘best’ – more likely is that they are better than others in some circumstances. Hence any conversation around deciding how much effort to spend on improving matters in any given situation becomes less objective, and more subjective, and therefore largely about what your gut instinct tells you.
Once the conversation enters this abstract territory it can become (as an old work colleague once described it) a game of Top Trumps where you use quotes from various industry ‘luminaries’ to try and back up your side of the argument. I suspect no topic in software development has anywhere near as many sayings as those about simplicity.
For example, in languages like C# and Java it is not uncommon to be faced with a solution to a problem which is implemented in a dizzying array of interfaces and classes when a couple of extension methods could just as easily do the job. For this scenario I like to play the John Carmack card [Carmack11]:
Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.
As the author of such seminal games as Doom and Quake his opinion should hold a lot of sway, but if you’re dealing with code from someone more classically trained you might need to draw on someone from a different era. Your deck probably holds a solid collection of quotes from the legendary Sir Tony Hoare (with the most heavily worn card likely being one on premature optimization) but I find this observation of his particularly useful for proposing further refactoring [Hoare]:
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
In extreme cases the protagonist may choose to counter with their performance card which luckily you can quickly neutralize with the aforementioned Sir Tony Hoare power card. But you may feel the need to finish off the round once and for all by hitting them with a double whammy by plucking out Hal Abelson’s famous words from Structure and Interpretation of Computer Programs [Abelson96]:
Programs must be written for people to read, and only incidentally for machines to execute.
For a trifecta you might consider playing Martin Fowler’s variation about any fool being able to write code a computer can understand, but an ad hominem attack like this would be more Donald Trump than Top Trump, so don’t.
The benefits of deleting code can never be overstated either, especially dead code and comments which provide no value, and, more importantly, code which can be further simplified by leveraging existing features of the language or standard library. For this we need to flick through the cards from our early 20th century section and draw something wonderfully profound from Antoine de Saint-Exupéry [Saint-Exupéry39]:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Not all programming quotes can or should be weaponised though. Sometimes we can be too quick to judge the efforts of our ancestors and ascribe the actions to malice or stupidity when in fact it was neither. This quote from Gerry Weinberg is a wonderful reminder about how hindsight is 20/20 [Weinberg]:
Things are the way they are because they got that way ... one logical step at a time.
I think we are fortunate now to be living in an age where less emphasis is being placed on talking about failure and more on using it as an opportunity to learn. The late Fred Brooks [Brooks] has a particularly memorable quote which I think extols that notion of continuous personal development:
Good judgement comes from experience, and experience comes from bad judgement.
Despite being relatively new in comparison to the maritime industry we are still blessed with plenty of our own expressions to draw from. As Andrew Tanenbaum once said (sic) “the good thing about quotes is that there are so many to choose from.”
| So, what does it mean? | |
|
References
[Abelson96] Harold Abelson and Gerald Jay Sussman (1996) Structure and Interpretation of Computer Programs, 2nd Edition, published by MIT Press.
[Brooks] Frederick (Fred) Brooks Jr (1931-2022) was an American computer scientist and software engineer, who wrote The Mythical Man Month. See https://en.wikipedia.org/wiki/Fred_Brooks
[Carmack11] John Carmack, posted 31 Mar 2011 on Twitter: https://twitter.com/ID_AA_Carmack/status/53512300451201024
[Hoare] Sir Antony Hoare, the quote is referenced in many places, including https://computerhistory.org/profile/sir-antony-hoare/
[Saint-Exupéry39] Antoine de Saint-Exupéry (1939) Terre des Hommes, (mostly) translated into English with the title Wind, Sand and Stars. See https://en.wikipedia.org/wiki/Wind,_Sand_and_Stars for an explanation of the differences.
[Weinberg] Gerald Weinberg, American computer scientist and author (1933-2018).
is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the comfort of his breakfast bar. He has resumed commentating on the Godmanchester duck race but continues to be easily distracted by emails and DMs.
