By Chris Oldwood

Overload, 31(175):19-20, June 2023

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?

The problem with expressions such as ‘ship-shape and Bristol fashion’ is that they aren’t always as obvious as you might think to people who haven’t heard them before. If you’re not from the UK – or you’re under 40 years of age (my guess) – you may not recognise them, or even if you do, your understanding of their meaning may be a little vague. A quick online search soon sorts it out, although you may find many suggestions of the origins of some! The current meaning is fairly standard, though, regardless of how the phrase started.

Ship-shape and Bristol-fashion: The ‘ship-shape’ part doesn’t have so much to do with the appearance (although that may be part of it) but more a claim that everything is as it should be, in its right place (construction and contents) – ready for sea. But why Bristol-fashion? Bristol is a historic port, but isn’t on the coast. Instead, it’s on a tidal river. This means that any ships – sometimes full of cargo – had to be able to withstand being dumped unceremoniously on the mud when the tide went out and cope with a strong tidal flow. The strain on the construction was greater than when floating. So, if ‘ship-shape’ is ‘ready to go’, ‘Bristol-fashion’ is probably the ‘high-quality’ element. (

Don’t spoil the ship for a ha’p’orth of tar: Interestingly (to me, anyway) although this is ‘obviously’ a nautical expression, that may not actually be where it started. It’s believed that ‘ship’ is actually ‘sheep’ (pronounced ‘ship’ in some dialects, and therefore written that way when literate non-farmers wrote it down) and ‘tar’ is tar – but was used to keep flies from sores, not to waterproof a hull. It does make sense with the commonly accepted derivation, though. (

Trying to save time/effort/cost when what you’re not doing is trivial in those terms but could have a devastating effect on the success of the overall project/task is the meaning, regardless of the origin.

Showing someone the ropes: The sails on large sailing ships were raised and lowered using ropes. And some had a lot of sails, and therefore a lot of ropes. It wasn’t always obvious which rope did what to which bit of sail. This is a straightforward one: making sure people know how to do what they have to do. (

Changing tack: Very much a nautical term, in use today. A sailing boat can’t sail directly into the wind, but tacking (changing its direction relative to that wind) enables the wind to alternatively blow into the sails from the port (left) and starboard (right) sides. This moves the boat generally into the wind, in a zig-zag pattern. (

Changing tack means changing the way you approach a task or an issue. Using different methods. Resolving an issue in a different way.

Onboarding: Sounds nautical, but appeared in the 1970s and always to do with new employees going through an induction programme. (

A sailing boat


[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

[Carmack11] John Carmack, posted 31 Mar 2011 on Twitter:

[Hoare] Sir Antony Hoare, the quote is referenced in many places, including

[Saint-Exupéry39] Antoine de Saint-Exupéry (1939) Terre des Hommes, (mostly) translated into English with the title Wind, Sand and Stars. See,_Sand_and_Stars for an explanation of the differences.

[Weinberg] Gerald Weinberg, American computer scientist and author (1933-2018).

Chris Oldwood 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.

Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED

By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED

Settings can be changed at any time from the Cookie Policy page.