Sunday, 1 October 2017

Textual description of firstImageUrl

Software Development - A Sisyphean Task?

It's rarely a pleasurable event returning from holiday. No matter how much you might enjoy your job it's still a sad event when that family time is over and you have to return to the more mundane routine of home, work and school. On arriving back you're never quite sure what emails are sat in your inbox or what post has landed on your doormat.

(I sincerely hope that you take the opportunity to take time away from emails on holiday - it's a holiday for a reason and the extra productivity from a genuine break far outweighs the apparent benefits of 'keeping on top of things' whilst away)

My return from holiday this year was markedly more pleasurable this year than previous years thanks to :

  1. My inadvertently buying double the amount I intended of a wine I'd never tasted at a spanish wine merchant and subsequently finding it to be quite delicious
  2. My finding a copy of Gojko Adzics new book 'Humans vs Computers' on the doormat as I arrived through my front door.

It's rapidly becoming one of my favourite books on software.The basis of the book is a series of lessons on the common pitfalls in software with strong and amusing anecdotes of projects that have suffered them.

  • Individuals getting charged tens of thousands of pounds for hotel rooms and car rentals because of decimal point position bugs
  • Computer systems refusing to initialise on 29th February as they didn't recognise it as a date
  • UK Post-codes failing to match because of inconsistency in how they handle the space between the incoming and outgoing postcode sections
  • US drivers being assigned huge numbers of fines due to inadvertently selecting number plate sequences matching the default text that traffic officers would enter in forms for a non-readable plate.

Whilst the stories that Gojko shares are amusing and eye-opening in equal measure, there is a more worrying aspect to them. The reason behind many such anecdotes being amusing is the fact that they strike a chord of familiarity with so many of us. The fact that so many people that have worked in software development, particularly testing, can identify with the calamities that can occur when working with leap years shouldn't really be trivialised as a subject for amusement. The problems with decimals that, as Gojko points out, cause so many embarrassing and costly mistakes, really aren't a laughing matter. I've spent my entire working life working with computer software and yet we still don't seem to be able to match addresses between different IT systems. We do seem doomed to making and discovering the same mistakes over and over again.

A sisyphean task?

I was chatting to a group of testing enthusiasts including Rob Lambert a while ago about the current state and future of testing. Rob in his eloquent way went on something of a diatribe about the fact that we won't be able to truly progress until we find ways to solve these same issues that come up again and again. I couldn't agree more.

When I started this blog it was with this post suggesting that software testing might be perceived as akin to the task of Sisyphus - forever destined to repeat the same activity. I wonder whether in actuality it is software development as a whole that on too many occasions is more like a Sisyphean task. Despite the availability of open source code repositories, shared libraries, Nuget Packages, development frameworks and ever more functional programming languages, we do still seem to have a habit repeatedly striving and struggling to solve the same issues that have been plaguing software development teams since the days of the BBC Micro.

Even casting my mind back over the last year or so I can recall examples of problems that I have encountered in exactly the 'classic' areas that provide such a rich supply of anecdotes for Gojkos' book.

  • Last year I was forced to implement a manual backup to an automated validation process for people using one of my systems as it was not possible to reliably check a match between postal addresses algorithmically between two separate systems
  • On a related system I was forced to prioritise a change to the UK postcode processing of an interface as an associated website provided postcodes without a space whereas our own system utilised and expected spaces.
  • A couple of years ago a system I supported encountered an issue where the 2015 leap second resulted in massive unexplained CPU usage requiring a server reboot to correct
  • In the last couple of weeks I've had to revisit discussions on calculation of performance figures in a customer dashboard as the example figures we were given demonstrated rounding up to the nearest integer whereas to maintain consistency with other systems we actually needed to always round down to one decimal place.

It's not all bad news

In a weekly publication I read there is a section "It wasn't all bad news" where they present some more light hearted stories from the week to stop the reader from being too depressed at the state of the world.

In a similar vein I'll leave with this sentiment. It may be easy to rue the apparent lack of progress in avoiding issues in software development, however at the same time there are still many reasons to be glad:-

  • Software testing as a craft is still very much needed.
  • Testing Heuristics have far greater longevity than expected and so our fantastic testing resources such as Hendrickson, Emery and Lyndsay's Test Heuristics Cheat Sheet are still valid and relevant.
  • We can enjoy great stories around software issues, such as those that Gojko has collected together in his book, relate to them and continue to share them even years later.

So I suggest taking some time to have a read of "Humans vs Computers" and maybe feel better about things the next time you can't match a postcode, or your software stops working on February 29th.

2 comments:

  1. Most of these issues occur where software meets the real world. I have started to think the real world needs to be simplified! No more clock change. No changing of timezone boundaries. And why not ban February 29th :)

    ReplyDelete
    Replies
    1. Love it - thanks Joe. Yes I agree it would be simpler if we could just start again, particularly with Calendars! As someone who previously had to manage 24x7 support across two teams, one UK and one California, I too would like to ban the clock changes. Sorry for taking so long to publish your comment I missed it first time around.

      Delete

Thanks for taking the time to read this post, I appreciate any comments that you may have:-

ShareThis

Recommended