Afterwood

Einstein famously told us to keep things as simple as possible, and no simpler. Hence, you’d think that being presented with a small snippet of simple code would generate a flurry of correct answers along with lots of metaphorical shrugging of shoulders and cries of “meh?” as people wonder what all the fuss is about. Jason Gorman, someone who specialises in training and coaching software teams, recently posted the following question on his various social media accounts [Gorman-X][Gorman-M]:

Quick experiment: what’s the expected result that’s been blanked out in this test code?

   [Test]
   public void FundsTransferDebitsPayer()
   {
     // Arrange
     Account payer = new Account();
     payer.Credit(1000.0);
     Account payee = new Account();
     // Act
     payer.Transfer(250.0, payee);
     //Assert
     Assert.That(payer.Balance, Is.EqualTo(_____));
   }

He doesn’t say what programming language this is written in but it’s fair to say it’s either Java or C# – a pair that are so similar these days they are easier to mix-up than Pluto and Goofy, or The Munsters and The Addams family. Either way, both these languages generally hold very few surprises, or dark corners that could lead to the pit of undefined behaviour. For those playing along at home, the answer really is just 750.0.

My own response was a somewhat guarded “750, right?”, followed by a flippant suggestion that if this was an interview there would almost certainly be some gotcha that I hadn’t accounted for. There wasn’t, this time, but nobody ever posts a snippet of code on social media that does exactly what it says on the tin, so is it any wonder that nearly every reply was caveated in some way? We programmers can be such a jaded bunch at times, our bodies metaphorically covered from head-to-toe in scar tissue.

Naturally I blame all those ridiculous interviews we go through where the apparent goal is not to hire someone capable of doing the job but to allow the interviewer to show the candidates how clever they are. If this code snippet was presented in a code review or generated during a pair / ensemble session I would hardly think twice about it. (That’s not entirely true because of the apparent ill-advised use of floating-point numbers for monetary values instead of using decimal in C#, BigDecimal in Java, scaled integer, etc. but that wasn’t the point of the question.)

Many of the teams I’ve worked in over the years have generally been of the ‘you build it, you run it’ stance and so your current teammates provide a useful barometer for what passes as ‘simple enough’. In a few cases, though, I’ve worked in The Enterprise™ where they have a different approach to maintenance, one where they hire a bunch of experienced developers to create a new service or application and then, when the first release is done, they hand it over to ‘the support team’ for any future bug fixes or enhancements. What surprised me was that this team mostly spends their time doing system administration but only gets to don their software developer hat occasionally.

This difference in maintenance approach made me consider the readers of my code more deeply than usual and this popular quote from The Elements of Programming Style [Kernighan78] took on a new perspective:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Consequently, patterns and idioms which, up to that point I assumed to be perfectly acceptable, I now felt less comfortable using and started questioning whether I was carrying over anachronisms instead of adopting more modern idioms that would make the code more accessible to this different audience. For example, as an industry we now discourage people from writing manual loops, and so maybe a retry loop in C# like:

  var attempt = 5;
  while(attempt-- > 0) { … }

is now becoming trickier to reason about when it comes to mentally checking the maximum number of times around the loop than:

  foreach(var attempt in 
    Enumerable.  Range(1, 5)) { … }

While the former technique might have been inherited from C by several popular languages, that doesn’t guarantee universal comprehension. It might be marginally less typing but as we embrace more functional idioms the latter style of code is becoming the new norm.

On the other hand, am I falling foul of Einstein’s advice and heading into oversimplification territory and as a consequence verging on patronisation? Can code become too simple?

What I liked about the replies to Jason’s experiment was seeing people answer their own questions about the code without realising it. As Alex Horne often says to contestants in this situation on Taskmaster, “all the information is on the task”, though in Jason’s example it’s in the names of the test, class, methods, and variables. Any other assumptions, like the default balance being 0.0, feel like a no-brainer too.

At some point we have to put our spade down and trust that the reader will engage their own brain. The trouble seems to be that the reader doesn’t always trust us to hold up our end of the bargain.

References

[Gorman-M] Jason Gorman’s Mastodon account: https://mastodon.cloud/@jasongorman/111601548580386385

[Gorman-X] Jason Gorman’s X account: https://x.com/jasongorman/status/1736733070726721935

[Kernighan78] Brian Kernighan and P. J. Plauger (1978) The Elements of Programming Style 2nd Edition, McGraw-Hill Education, ISBN-13 978-0070342071

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.