investigating software

I play a card game called cribbage. I often play it with my son . One interesting part of the game is the muggins rule. This means that you can claim points from other players turns, if they miscount the score.  The scoring is slightly nerve racking, with each of us double and triple checking our scores, to avoid falling foul of ‘muggins’, that’s part of the fun.  But my son and I also find ourselves discussing other hands of cards, in a sort of alternate history version of the game. “So if I had a 7 instead of a 2 of hearts, then I’d get a double run and score at least 8 more points”.   “Yes Dad, if you had different cards then you would likely have a different score, but you don’t” he says while rolling his eyes.  This sort of bitter-sweet history rewriting is a convenient tool for us to swallow the awkward truth of the real world. We often create alternate things to object to.  Take Chat GPT 4 and tools like Copilot X. These are powerful tools, capable of doing useful tasks quicker

 I was lucky enough to have started my career in a small company and then in a start-up. Both provided me with an environment perfect for learning. I sat with experts who took time out of their day to help answer my questions. From them, I learned the basics of what I still use today.  I’ve built on those foundations, but things would have been much harder if I didn’t have those foundational moments of my career. I’m not just talking about technical skills, the mentoring on how companies work, consulting and how to be better generally.  But those technical skills were also a big part of it – and a part many people miss out on in their careers. The rise of Large Language Models like ChatGPT4 is rapidly helping to fill that gap – where people don’t have a technical mentor who can explain and help work through those technical problems.  I’m no longer that junior team member – asking the dumb questions (OK, well usually I’m not) but even I find Chat GPT excellent at consolidating a broad s

I recently open sourced a simple Micropython library for LoRaWAN on the Raspberry Pi Pico.  (If you are interested, You can find it on GitHub .) If you are unsure what that all means, let me unpack it for you... Micropython is a slimmed down version of Python 3.x that works on microcontrollers like the Raspberry Pi Pico, and a host of other microcontroller boards .  LoRaWAN is a wireless communication standard that is ideal for long range, low power & low band width data transmission. Its based on a clever technique for making signals work well over distance, called LoRa. The library I've shared is a wrapper around the existing LoRaWAN support provided by the RAK Wireless 4200 board. The RAK4200  (affiliate link) essentially provides a modem, that can establish a connection to the network and relay messages. It uses the traditional AT command syntax (used by the modems of yore!) The Pico and RAK4200 Evaluation board (there is also a UPS under the Pico there - that's optio

“Works on my machine!” “Fails most epicly on my test system!” “Oh, wait… it works on CI but fails in Test env 3.” Sound familiar? These sorts of conversations are thankfully a thing of the past.  Wait, hold on - are you still having these sorts of conversations? That's probably because you are working somewhere where the development, test, production & CI servers are being created by people, painfully, once. Alexander the Great cutting through the Gordian knot of a particularly gnarly micro-service deployment. You set up your laptop, you pray to the god of operating system patches and upgrades and hope that nothing ever changes (ever). You're gonna be the last person in the team to take that new Mac OS upgrade - let the rest of the team run through those mine fields first. And the test systems? Last time you asked for a new one of those your programme manager ended up on new & stronger heart meds. Luckily, there are tools that can help.  Gitpod , for example, allows you

Sometimes people discuss test engineers and QA as if they were a sort of police force, patrolling the streets of code looking for offences and offenders. While I can see the parallels, the investigation, checking the veracity of claims and a belief that we are making things safer. The simile soon falls down. But testers are not on the other side of the problem, we work alongside core developers, we often write code and follow all the same procedures (pull requests, planning, requirements analysis etc) they do. We also have the same goals, the delivery of working software that fulfills the team’s/company's goals and avoids harm. "A few good men" a great courtroom drama, all about finding the truth. Software quality, whatever that means for you and your company is helped by Test Engineers. Test Engineers approach the problem from another vantage point. We are the lawyers (& their investigators) in the court-room, sifting the evidence, questioning the facts and viewing t

This is the story behind the VW emissions scandal, that so far has cost the company over $33bn.  We look into the technology issues VW faced and the investigations that uncovered the problem. The MP3 (Audio) file is available here .

As part of an ongoing project to learn more about what we've got wrong to help us improve, I look at the Therac-25 incidents, a devastating collection of software failures that often rank in the top 10 of civilian radiation accidents. The Therac-25 radiation therapy device killed or injured 6 people across Canada and the United States. The Therac-25 was a room-sized machine, in this cut-away, you can see the computer terminal in the near-bottom left. I look into two of the most severe bugs. Why the manufacturer didn't fix them and what we can learn from their mistakes. The MP3 (Audio) file is available here .