Performance testing and engineering is typically thought of as a purely technical concern. However, in our experience across many varied industries and organisations, it’s the people in key non-technical roles that can have the greatest impact on both the performance of the end product and the sanity of the delivery team.
Many system quality issues (including performance) can be traced back to fateful decisions earlier in the life of the delivery project. This understanding is driving an industry-wide shift-left trend - pushing quality activities earlier in the life-cycle.
Unfortunately shift-left in Performance Engineering usually stops with developers. Development teams are working more closely with testers and operations teams to tune and mitigate performance issues early. But we need to go further than that - back to the moment a Product Owner thinks “Gee, I bet our customers would love Feature X, let’s make a business case for that”. It’s from that point onwards that everyone should start considering performance as they plan and make decisions.
Too often, from ideation through to development (and sometimes past that), functionality is the cool kid on the block. It’s all too easy for everyone to get excited about fancy new Feature X and the cool things it can do, and simply assume that Google-like speed and scale will come for free. Feature X gets approved, goes through the usual analysis and design process, and development begins. It’s often left to testers and developers who have to be the bearers of bad news and say, ‘Hey feature X is great and all, but the response times are over 2 minutes if more than 5 people try to use it at once’.
After all that effort and excitement, poor old Feature X has gone from the hero feature release of the year, to a performance trash fire that’s burning the project to the ground. And on top of that, now you have:
It’s usually about this point that our Test and Optimisation experts get called in to help put out the fire. Most of the time we can figure out how to make it all work and hum and realise the potential of Feature X that the Product Owner first envisaged. But it’s mucheasier (and often cheaper) for everyone when performance has been considered along the way - by everyone having a performance mindset.
What does having a ‘performance mindset’ actually mean? It’s not about becoming an expert in performance tuning. It means considering performance as wellas functionality when approaching your daily tasks.
Specifically, what could a Product Owner, PM, BA, and UX Designer do differently to help avoid the above situation? Here are some of the key behaviours that separate the great from the merely good.
Our mission as Test and Optimisation consultants isn’t just to ‘test x’ or ‘make y go fast’. It’s to make our expertise as valuable as possible, which means helping you avoid those performance fires in the first place. Kind of like that awesome movie ‘Inception’—if you can get in early and instil a ‘performance mindset’ across all stakeholders then everybody wins.