In my previous post, I contrasted two different terms for thinking about how people interact with your organisation – Customer Experience (CX) and User Experience (UX). Rebecca Brown (a CX expert I mentioned in the post) kindly explained her view of CX to me, which got me thinking of some quality and process things that … Continue reading Customers, suppliers and fences
Category: Quality
Using User Experience Techniques to Introduce Mutation Testing
Someone posted a question in a Ministry of Testing Slack channel about introducing mutation testing at work. My answer is below, as someone suggested I turn it into a blog post. I've edited it slightly to make it stand on its own rather than as a response to a particular person's question. It's basically a … Continue reading Using User Experience Techniques to Introduce Mutation Testing
Emotion and software development
I vividly remember an appointment with a sonographer when my wife was pregnant. On one hand, it was a skilled professional using a combination of acoustic gel, a wand that contained a microphone and loudspeaker, a portable computer that did signal processing on what the microphone picked up, and a monitor that displayed a visual … Continue reading Emotion and software development
Performance optimisation – for machines or people?
I recently watched a video and listened to a podcast that form an interesting pair of opinions about performance. The video is Patterns for high-performance C# and the podcast is SE-Radio Episode 357: Adam Barr on Software Quality. There are two things where the podcast and video have no differences: the system must behave correctly, … Continue reading Performance optimisation – for machines or people?
Going a bit deeper with Don’t Repeat Yourself (DRY)
DRY, or Don't Repeat Yourself, is a principle of software engineering. It makes code quicker and easier to understand and to change. For instance, instead of having the same chunk of code typed out twice or more, you carve it out into a method and then call it each time you need it. However, I … Continue reading Going a bit deeper with Don’t Repeat Yourself (DRY)
Fault tolerance
Introduction I am slowly working my way through the 300+ back issues of the podcast Software Engineering Radio. I've got as far as a couple of excellent episodes on fault tolerance with Bob Hanmer. I recommend that you listen to them, even if (like me) you don't have to worry about this kind of thing … Continue reading Fault tolerance
Single-step your code before you hit bugs
Introduction The habits or practices you adopt as a programmer influence your productivity and the quality of your output. The consequences of these practices can be good or bad, intended or unintended. After a brief stop off at the practice Test-Driven Development, I will go into another one: using a debugger to single-step your code … Continue reading Single-step your code before you hit bugs
I couldn’t possibly comment
While there is always some new tool or technique to learn in programming, there are other things where you think you've already got it sorted. Commenting your code is one of those things for me. When I read a recent article on comments, that asked if comments were good or bad, I thought "Obviously, they're … Continue reading I couldn’t possibly comment
Designing your system for when it fails (which it will)
A couple of excellent related videos from Goto Conference 2017. Some highlights are below. Metrics are better than nothing, but some context will make them much more useful. (My queue is filling up - is that because more things are arriving than I'd expect, or things are leaving more slowly?) Alerts and logs better than … Continue reading Designing your system for when it fails (which it will)
Here be dragons: testing your error handling code
Who tests the error handling parts of their code? You might want to start doing this after watching this very interesting video from Goto Conference 2016. Among other things, the speaker summarises a paper that investigates catastrophic failures in things like MapReduce, Cassandra etc. 58% of the catastrophic failures could have been prevented by testing … Continue reading Here be dragons: testing your error handling code
