Over-Promise, Under-Deliver

’Tis the time of New Year Resolutions, new beginnings, and even an opportunity to write an editorial for the very first time. So much potential. However, I have not seized the chance, so we will have to cope without an editorial. We knew an editorial was highly unlikely, but dreaming about change or possibility can inspire and give hope, so we should be encouraged by the opportunity for a new start.

The trouble with New Year’s Resolutions is we often start well then fail. Recently, I have been trying to learn bass, yet again. I managed to practise every day for over a month before Christmas, but a one night stop-over killed my streak. It is very easy to think, “I’ve blown it” and give up completely. That would be foolish. I managed to persuade myself I simply had a day off, and this means nothing significant about me, my determination, or my abilities. I simply cannot manage to do everything I want to do every day. It’s perfectly fine to aim to do something every single day, as a motivation, but miss out once or twice. Aim high, by all means, but accept a few misses. By the same score, if I miss a note when I try to play bass, that’s fine particularly because I am playing alone and no one can hear the mistakes. Even if I were playing with a band, I could continue on and forget the mistake and just about get away with it.

An occasional mistake in code might be acceptable, but there are many circumstances where a bug could be fatal. Various approaches have been adopted to avoid problems, including the UK government’s ‘SafeIT’ research program, leading to the development of the Motor Industry Software Reliability Association (MISRA) guidelines for vehicle based software in the 1990s. The recent release of MISRA C [MISRA-1] and MISRA C++ [MISRA-2] has caused mention in a few places, but I have yet to see the full details. Though I have worked with embedded systems, they tended to be barcode scanners, or similar, rather than vehicles. The most dangerous thing I ever managed was undefined behaviour causing the laser scanner to stay on. Now, MISRA is used for more than vehicle software, and may be found in sectors ranging from NASA to medical devices. Whether the guidelines actually improve safety is hard to prove. To be certain you would need to clone the development team and let them code the system independently, one using the guidelines and one not. That is problematic, but then you need to test for differences in safety, which might prove even more difficult. More simply, some research on software reliability is available, for example Boogerd and Moonen conducted a case study investigating MISRA:C 2004 rule violation and actual faults [Boogerd08]. Be warned, they suggest, “Enforcing conformance to noisy rules can … increase the number of faults in the software.” However, they also conclude “It is important to select accurate and applicable rules” and that doing so can make software more reliable. If used judiciously, guidelines can improve software.

There are various other guidelines for programming languages beyond MISRA. The ISO C++ Core Guidelines [ISO] and Google’s C++ style guide [Google] come to mind, together with various linting tools. If you have ever started using a static analysis tool on a code base, you may have found yourself drowning in rule violations. Though Boogerd and Moonen’s paper mentions frequent high levels of false positives from various tools, you might also find many true positives hiding in the output. Where do you start with a flood of warnings or problems? The tool you are using might promise to find every potential problem with your code, so you shouldn’t be surprised if it seems to flag up almost every line of code. The important thing to do is apply some sense or discernment to the output. You can often silence various types of rules in a tool, making it easier to concentrate on specific types of problems. I recall being asked to conduct a Python code review a long time ago, and ‘cheating’ by pointing PyLint at the code. I silenced the complaints about single letter variable names, and noticed we had hidden a keyword by a bad choice of variable name. Without silencing a large number of ‘problems’, I would have missed a real problem. When I mentioned the name hiding in the code review, I was asked how I spotted this. I owned up and got a wry smile from the person who had written the code. We could have incorporated PyLint into the build, but didn’t at the time. However, it did give us an extra way of investigating or reviewing new code.

Many tools claim to help us write better software, more quickly. Whether they do or not is another matter. Marketing often over-promises, and the goods sometimes under-deliver. If a tool provides something useful and doesn’t cost the earth that might just be good enough. You don’t have to fix every potential problem immediately. It is sometimes said that perfect is the enemy of good, so finding anything that helps a bit is a good thing. Aiming for perfection can make you freeze up and achieve nothing. Similarly, staring at a blank page makes it very difficult to write an editorial. Having something to start with, no matter how bad or irrelevant, gives you something to improve on. If you have broken any New Year’s resolutions you made already, don’t panic. Maybe you achieved something for a while, so you can be pleased with yourself and try again later. Don’t forget the 80/20 rule, also called the Pareto principle. If you focus on changing 20% of what you don’t like, you might end up with 80% improvement. Of course, that is hopelessly vague and doesn’t specify what improvement or even change means, and the original Pareto observation related to property ownership [Wikipedia]. The salient point is that altering one thing might have many other impacts. They might even be positive. If you wait until you have listed everything that needs fixing, you are less likely to achieve anything.

The ultimate overpromise may be attempting six impossible things before breakfast. The original quote is from Through the Looking Glass by Lewis Carroll, wherein the Queen says she has sometimes believed as many as six impossible things, rather than achieved them. However, if you were to aim for six impossible things, but only managed one, you are doing better than most people. If you don’t want to believe or attempt anything impossible, you could try something possible instead. Maybe the New Year brings you a new project at work, or the chance to prepare a new talk for a conference or meetup. My ACCU conference proposal has been accepted, so I need to start writing it. Doing something new, especially if it involves something you have never done before, can be daunting. It would be much simpler to talk about techniques I already know and can rattle off without preparation; however, that would be boring. The opportunity to learn something new is exciting. I will learn about cat swarm algorithms. Yes, that is a thing: a ‘cat’ either traces or seeks, and algorithms can be built based on these modes to find solutions to problems [Chu06]. I hope to be able to explain this in more detail in a couple of months. Herding cats may be used as an example of something foolhardy and impossible, but implementing a cat swarm algorithm can’t be that hard, surely? Watch this space.

Aiming to do something easy is lazy, whereas trying to do something you have never done before is admirable though risky. If I try this cat swarm optimisation, I might not understand it properly. I won’t let fear of failure put me off though, and neither should you. ACCU members are supportive and easy to talk to, so I know I have people I can turn to if I get stuck. Perhaps you should be brave too. If you aren’t going to speak at a conference, and have no intention of ever doing so, fair enough. Maybe consider writing an article instead? Or, try some of the puzzles and challenges in our member’s magazine CVu, or write a book review. You get a free book if you get in contact with the reviews editor.¹ Push yourself outside your comfort zone this year. Like exercise in the gym, you may feel uncomfortable for a bit, but maybe you will experience some feel-good endorphins and make yourself a little stronger.

Staring at a blank page, as I said, can cause writer’s block or similar. Now, AI doesn’t suffer from this. Generative AI can waffle away easily enough. In fact, most AI algorithms may start by trying something at random, and then incrementally improve. Much of the agile movement encourages us to take a similar approach. Make something, a minimum viable product (MVP) for example and see how it goes. The important part is not just making a product, but observing its use. Rather than aiming for something to make money from, an MVP has “the additional criteria of being sufficient to learn about the business viability of the product.” [Agile]. Trying something and using feedback to guide what happens next is an essential part of so many things, including software creation, AI, and learning in general.

Seeking feedback is one thing, but unsolicited feedback can prove incredibly unhelpful. I went for a walk round the block the other day, and noticed two ladies walking a dog. One was clearly the owner and the other a dog/dog-owner trainer. The dog’s owner said “Heel!” as I went by, and I could hear the trainer saying you don’t need to correct the dog unless they do the wrong thing. The dog had come to heel, but not lined up perfectly. I am not a dog owner, but I can see how being critical when something is approximately right is not the best way to encourage behaviours you want. It is difficult to say “That’s really good, well done. Maybe next time, we can do even better!” each time feedback is requested and you notice something amiss. Maybe you can be more critical with some than others; however, let’s all try to remember to be kind and encouraging whenever possible. If you are being drowned by negative feedback, and are not in a position to find better collaborators, then don’t be shy about asking which the best parts were to remind others pointing out the good is as important as pointing out the bad.

Lots of people seize New Year, or any ‘significant’ date, as a time to write dimly related blogs or mail shots and this year is no exception. One that caught my eye touted the old aphorism, ‘Goals without plans are just wishes.’ Now, there is an element of truth to that. I can write down several goals, like continuing to play my bass. However, without specifics of what to play, practice exercises, and the like, I probably won’t make much progress. Now, I don’t need to plan out precisely what I plan to do when, but a handful of songs to try and scales to practise is enough to make a start. I may not have a fully formed plan, but I do have a goal. And anyway, what’s wrong with wishes? I wish you all a Happy New Year, and along with the review team, am here to encourage you and maybe you will manage something you thought was impossible this year, even if you don’t get around to everything you hoped.

References

[Agile] ‘Minimum Viable Product (MVP)’, definition in the glossary of the Agile Alliance: https://www.agilealliance.org/glossary/mvp/

[Boogerd08] C. J. Boogerd and L. Moonen (2008) ‘Assessing the Value of Coding Standards: An Empirical Study’, preprint of a paper published in ICSM 2008 (IEEE International Conference on Software Maintenance, 28 September–4 October 2008, available: http://resolver.tudelft.nl/uuid:646de5ba-eee8-4ec8-8bbc-2c188e1847ea

[Chu06] Shu-Chuan Chu, Pei-Wei Tsai and Jeng-Shyang Pan (2006) ‘Cat Swarm Optimization’, available https://www.researchgate.net/publication/221419703_Cat_Swarm_Optimization

[Google] Google C++ Style Guide: https://google.github.io/styleguide/cppguide.html

[ISO] C++ Core Guidelines (Bjarne Stroustrup and Herb Sutter, editors): https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

[MISRA-1] MISRA C:2023 https://misra.org.uk/misra-c2023-released/

[MISRA-2] MISRA C++:2023: Guidelines for the use C++:17 in critical systems https://misra.org.uk/misra-cpp2023-released-including-hardcopy/

[Wikipedia] Pareto principle: https://en.wikipedia.org/wiki/Pareto_principle

Footnote

1. See https://accu.org/menu-overviews/reviews-overview/ for details.

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD using AI and data mining. She's written a book about machine learning: Genetic Algorithms and Machine Learning for Programmers. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.