investigating software

It's August 1941, during the opening years of WW2, the axis powers had conquered much of mainland Europe -and the Allies were desperately trying to limit the capacity of the axis military industrial complex. They did this with little feedback on their success - much like some modern teams using AI tools. The Royal Air Force's (RAF) strategic bombing campaign had applied considerable resources to the task of diminishing continental targets such as occupied French ports or the factories of the Ruhr valley. Much as the northwest and northeast of England were the industrial centres of Britain, the Ruhr was where a large part of the Axis industrial might lay, and so was an important military target.  The air crews reported back after their sorties (missions), stating how successful their missions had been. If such reports were to be believed, Germany and the axis powers should be decimated, be ‘on their knees’, and would fall or at least falter in short order. Wisely the air min...

I was raised in a world full of rules, like all of us, though as I grew up in a military family in and around military bases - so maybe a bit more so for me. As a parent myself, rules are at play - "no son you can't bang our wooden table with an old hammer". Even the business world is full of rules, don't agree? Speak to your bank's payments or compliance department or your lawyer or accountant and get back to me. We soak up all sorts of rules like sponges, implicitly.  Like my toddler son when he found my old hammer, "no the rule is I can't bang the table with the hammer - when you are in the room" - while he has reverse engineered the rule and context perfectly - Though I feel he didn't pick up on the full spirit of the rule. The late author David Graeber had a talent for analysing rules in societies old and new. He used "opposites" as a way to elucidate the rules and assumptions at play in fiction and in society. A good example he us...

 Ever tried to get a teenager to do more chores around the home? For those without this joy in their lives, I’ll let you in on a secret - it goes down like a bucket of sick. You can sometimes cajole them, sometimes bribe them and even threaten them (We’ll take away your laptop!) But at best, this has mixed results. You’ll often get an uptick in throughput - the rubbish & recycling will exit the apartment more often. But quality will suffer, the cacophony of bins being banged, incessant grumbling and milk cartons being scattered about will lead to you questioning many of your life choices. This is often the case in life generally and software development in particular. The old adage “Faster, better, cheaper - Pick any 2” still holds true. Interestingly this isn’t always bad news for those in the business. More often it's a problem for customers, be they other teams or actual customers .  For example, if you provide the means to produce faster - more people may be buying you...

  A nervous tourist, glances back and forth between their phone and the street sign. They then rotate their phone 180 degrees, pauses, blink and frown. The lost traveller, flags a nearby ‘local’ (the passer-by has a dog on a lead.   “Excuse me…” she squeaks, “How may I get to Tower Hill?” “Well, that’ s a good one” ponders the dog walker, “You know…” “Yes?” queries the tourist hopefully. “Yeah…” A long pause ensues then, “Well I wouldn’t start from here” He states confidently. The tourist almost visibly deflates and starts looking for an exit. That’s often how we start off in software testing. Despite the flood of methodologies, tips on pairing, power of three-ing, backlog grooming, automating, refining and all the other … ings ) We often find ourselves having to figure out and therefore ‘test’ a piece of software by us ing it. And that’s good. Its powerful, and effective if done right. But, like our dog walker, we can sometimes find ourselves somewhere unfamiliar...

 The beginning of the hitch-hikers guide to the galaxy leads with an alien ship about to destroy the Earth, and the aliens saying we (mankind) should have been more prepared – as a notice had been on display quite clearly – on Alpha Centauri the nearby star system, for 50 years. Seriously, people - what are you moaning about – get with the program?  The book then continues with the theme of bureaucratic rigidity and shallow interpretations of limited data. E.g. The titular guide’s description of the entire Earth is one word: “Harmless”, but after extensive review the new edition will state: “Mostly harmless”. Arthur Dent argues with the Vogons about poor data access This rings true for many software testing work, especially those with externally developed software, be that external to the team or external to the company. The same approaches that teams use to develop their locally developed usually don’t work well. This leads to a large suite of shallow tests that are usually h...

When it comes to rolling out updates to large complex banking systems, things can get messy quickly. Of course, the holy grail is to have each subsystem work well independently and to do some form of Pact or contract testing – reducing the complex and painful integration work. But nonetheless – at some point you are going to need to see if the dog and the pony can do their show together – and its generally better to do that in a way that doesn’t make millions of pounds of transactions fail – in a highly public manner, in production.  (This post is based on my recent lightning talk at  PyData London ) For the last few years, I’ve worked in the world of high value, real time and cross border payments, And one of the sticking points in bank [software] integration is message generation. A lot of time is spent dreaming up and creating those messages, then maintaining what you have just built. The world of payments runs on messages, these days they are often XML messages – and they ...