Hiccupps

The Test team book club is reading Guide: Achieving Observability from Honeycomb , a high-level white paper outlining what observability of a system means, why you might want it, and factors relevant to achieving and getting value from it. It's not a particularly technical piece but it's sketched out to sufficient depth that our conversations have compared the content of the guide to the approaches taken in some of our internal projects, the problems they present, and our current solutions to them. While I enjoy that practical stuff a great deal, I also enjoy chewing over the semantics of the terminology and making connections between domains. Here's a couple of first thoughts in that area. The guide distinguishes between monitoring and observability . monitoring: "Monitoring .. will tell you when something you know about but haven't fixed yet happens again" and "... you are unable to answer any questions you didn’t predict in advance. Moni...

This year I've read three books that follow projects from the perspective of individual contributors, managers, and the business. They are The Goal , The Phoenix Project , and The Soul of a New Machine . The Goal is perhaps the most well-known. It's a pedagogical novel in which a manufacturing plant manager is given three months to turn his failing plant around. He stumbles across a mentor who, with well-chosen questions and challenges, exposes the fallacies of the traditional production models being followed and suggests new ways to analyse the business. The philosophy at the heart of this is the Theory of Constraints , where constraints can be anything that gets in the way of the business goal, and the aim, as described by a couple of its key players is "not so much to reduce costs but to increase throughput". (p. 298, Kindle) The Phoenix Project is also fictional but this time set in the world of IT, Ops, Dev, and Test. Again, the main protagonist is unde...

A couple of years ago our book club at work read On Testing Non-testable Programs . At the time I idly wondered whether I could use it to make an ontology of oracles but didn't pursue the idea beyond finding that Doug Hoffman had already provided a classification scheme back in 1998: A Taxonomy for Test Oracles The other week he presented a webinar, The Often Overlooked Test Oracle , which built on some of that earlier work, outlining a range of oracle types with pros, cons, and other notes. I like theory like this that can guide my practice and I'm still practicing my sketchnotes so I tried to capture the set of oracles he covered in a sketch. I'll just leave it here.

I got my dad a Bear Grylls book, How to Stay Alive: The Ultimate Survival Guide for Any Situation , last Christmas. He keeps it in the toilet — in case of emergencies, presumably. Flicking through the bright orange volume at the weekend, a section on being lost caught my eye. Having spent a proportion of the last four weeks struggling to understand a performance testing experiment, I am currently very familiar with that sense of bearings going AWOL. Grylls is largely concerned with physical endurance in extreme environments. Clearly, the stakes are somewhat different for me, at my desk, wrestling with several databases, a few servers, a set of VMs and their hypervisors, numerous configuration options, and the code I've written to co-ordinate, log, and analyse the various actions and interactions. Yet, still, Grylls' advice says something relevant to me: Millions of people get lost every year ... Their critical faculties grow impaired and they become less able to m...