The Software Mechanic

The Software Mechanic

Having explained the role of a software tester to a non IT person they replied:

So it’s like I’m taking my car to a garage to get serviced by a mechanic and all that the mechanic does is to find everything that needs to be fixed, tell me and walks away? The Software Mechanic

To which I muttered, “there’s a bit more to it than that, but yeah, that one way of looking at what I do.

This simple but effective analogy (and his incredulity) has never left me even ten years on. Recently, chatting with Maaret Pyhäjärvi on the quality coach podcast, we talked about having a mindset to “get stuff into the hands of the consumer as fast as possible”. She mentioned how she’s encouraging her intern to not only find bugs but fix them too. Find and Fix. Find and Fix. In this way, she shortens the feedback loop and focus on delivering value to the consumer faster.

Smashing these two ideas together, the concept of software mechanic is born. Where, instead of focusing on finding bugs, instead we focus on finding and fixing them. Because, fixing bugs is the end game. It’s what we all want, improved quality. We don’t want an endless list of bugs weighing down our ability to move quickly.  We want bugs found, fixed and forgotten.

And, every bug has a cognitive load associated with it (another Maaret  gem). Knowing these bugs exist, adds to our list of “things we should be doing”. We try to ignore them. But, like monkeys on our backs, they cling on. They slow down our progress, impede our flow until in frustration we stop. We call these ‘bug fixing days’. Everyone commits to spending at least 1 day bug fixing in order to reduce tech debt.

Software mechanics have skin in the game. Skin in the game means you’re invested in the outcome. Being invested in the outcome changes perspective. Instead of focusing on building extensive test automation, the goal becomes fixing bugs and releasing software.

It should remove some of the friction within teams. Instead of that push/pull between tester and developer, everyone is visibly contributing to the end goal.

And similar to a car mechanic, a software mechanic suits an apprenticeship model.  Software development requires applied knowledge to achieve competence. Finding bugs, especially bugs that matter, demands we see our system from an outside perspective. The perspective of the consumer and the business.

Finding bugs also requires we understand our systems, how the pieces hang together and interact with each other. Experience software developers know this knowledge is gold. Add bug fixing to the mix and you get hands on coding experience, in a safe to fail setting.

What do you think?  Would you like to be a software mechanic?

If you like this post, you might like these:

2020: The year of dumping old heuristics
When software testing, it’s handy to use mnemonics/heuristics to refer to. They can be useful as generators of test ideas, or reminders to test in a particular way, or to consider some aspect. What’s a heuristic? Think of a heuristic as a rule of thumb
Damn it all, its just not cricket..or is it?
After fifteen years of living in Australia, some things have rubbed off on me. One of the them is cricket. I have to confess I have spent many a sun drenched day watching the cricket whilst imbibing the odd beverage here and there. One thing that I have noticed in
Do your bugs only glow when its dark?
Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports! I do a lot of offsite exploratory