The Software Mechanic

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:

3 thoughts on “The Software Mechanic

  1. Over the years I learned that information can be ignored but actions are harder to ignore. If I found small bugs and along with those reports I provided the fixes, it meant I didn’t have to advocate for someone else to fix them. It saved me time and energy. Plus less risk of someone saying no!

    I’ve literally been telling myself to write something on this topic for 3 years! In all that time the idea of Software Mechanic never took shape. Thanks for putting it out there! Props to Maaret too!

Leave a Reply

Your email address will not be published. Required fields are marked *