The Hacker Mindset or Breaking Something to Make It Work

That’s impossible! And yet, some time later, we’re very much doing it. 

My day to day work is about software testing – breaking illusions about software. We build systems and features of value, with best of intentions. Yet sometimes we miss a perspective. Some people think testing breaks software, but it was broken, the only thing broken were people’s illusions. The illusions we hold can make us head straight into trouble, invest a lot into something where we don’t yet know exactly how to get to value, or end up unable to scale as we’re solving problems when we should be selling.

Getting impossible things done is not about doing the impossible, but changing people’s minds about what is possible. While you may know software testing as an idea of finding problems in products, the illusions we need to break for successful endeavors in companies come in more forms than that. 

The illusions we hold can make us head straight into trouble, invest a lot into something where we don’t yet know exactly how to get to value

 

Basic illusions in software systems are about the code doing what it was supposed to, product doing what it would need to, and product doing only what it is supposed to. From mistakes in implementation, to mistakes in requirements and mistakes in security, all relevant perspectives in building the right product, and building it right. 

Other illusions are about the ideas that lead to code. Process being able to help us deliver with change in mind, people having the skill to deliver well and business model driving the selection of right focus. 

Getting impossible things done is not about doing the impossible, but changing people’s minds about what is possible.

With 25 years in the industry, I’ve been lucky enough to go through similar experiences with different companies. The more time I spend with the products and services we build, the more I realize the importance of us all having a mindset encouraging us to break illusions to see what can work. 

In one company, we had been designing a significant feature that the customers indicated they wanted. Asking around, showing designs, talking about the idea – all positive. The effort to build it was significant, and we were all eager to take the step towards adding the feature. We identified the riskiest assumption: customers being ready to pay for the added value. We construed an experiment, identifying a falsifiable hypothesis: we believe that customers are willing to pay extra for X. To the shock of my fellow software people, we construed an experiment of prepayment with an ambitious delivery schedule – to learn that our riskiest assumption of extra money in the value did not hold true. 

In another company, we looked at research around DevOps, a continuous delivery model with connections to business success as per book Accelerate by Nicole Forsgren et al. We deemed continuous delivery – frequent releases – impossible, but again defining an experiment after experiment, learned how to do continuous delivery without test automation (but lots of build automation). Later from the same premise of impossible we learned that you can do continuous delivery with products installed on personal computers and users in the millions and it changes the product risk profile and scheduling reliability for the better. 

Trying something that could fail is our chance of seeing some of our experiments succeed.

Major changes we seek start from breaking illusions we hold dear from our own experiences. Allowing myself to sit with developers programming on a single computer – a practice known as ensemble programming – we didn’t have 6 people working on one person’s job, but a more fluent way of building the best out of everyone into the work we were doing, optimizing scope and quality in a way that turned positive for ability to deliver. Having no product owner turned a product team into a high-performing collaborative unit. 

It all starts with identifying something we are ready to look at critically, regardless of the beliefs we hold, and measure the outcome. My favorite saying these days is that FAIL is the First Attempt in Learning. Trying something that could fail is our chance of seeing some of our experiments succeed. You can’t prove something is true, but when you try your best to show it isn’t true and fail at those attempts, you’re standing on a stronger ground. 

Maaret Pyhäjärvi is an exploratory tester extraordinaire with a day-job at Vaisala as Principal Test Engineer. At SHIFT 2020 she will expand on what one can learn from breaking something in order to get it to work better.