Robust Software - Dotting the I's and Crossing the T's

By Chris Oldwood

It’s been said that the first 90% of a project consumes 90% of the time, whereas the second 10 % accounts for the other 90% of the time. One reason might be because elevating software from “mostly works” to robust and supportable requires an attention to detail in the parts of a system that are usually mocked out during unit testing. It’s all too easy to focus on testing the happy paths and gloss over the more tricky design problems such as how to handle a full disk or Cheshire cat style network.

This session delves into those less glamorous non-functional requirements that crop up the moment you start talking to hard disks, networks, databases, etc. Unsurprisingly it will have a fair bit to say about detecting and recovering from errors; starting with ensuring that you generate them correctly in the first place. This will undoubtedly lead on to the aforementioned subject of testing systemic effects. Finally there will also be diversions into the realms of monitoring and configuration as we look into the operational side of the code once it’s running.

At the end you will hopefully have smiled at the misfortune of others (mostly me) and added a few more items to the ever growing list of “stuff I might have to think about when developing software”.