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.

Shifting Performance (further) Left

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:

• An angry Product Owner who didn’t even know this could be a problem
• A freaked-out PM who didn’t allocate enough time or budget to tune performance issues
• A confused BA doing a crash course on non-functional requirements
• A frustrated UX Designer who thinks this has nothing to do with them

The Performance Mindset

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.

Product Owners:

• Keep in mind that users demand performance as much, if not more, than cool new features and functionality. Users are going to hate Feature X if it doesn’t perform.
• Be aware that some features will result in a trade-off in performance. Pitch Feature X to your engineers early to determine if a cost/benefit analysis needs to be done.
• Consider how Feature X will impact user numbers and behaviour. How many new users would you expect? Are you targeting mobile users? Will they live in rural areas with flaky network connectivity?
• How will Feature X be launched? With a big fanfare and publicised start date/time? (think Census). Or staggered over numerous days/hours or user groups?

Project Managers:

• Budget time up-front for performance optimisation within development sprints/phases, not just ‘ad-hoc if necessary’.
• Ensure performance criteria are a mandatory part of your ‘definition of done’ before moving on to the next sprint/phase.
• Plan ahead and save wasted time by ensuring your team are well-equipped by sourcing and driving the timely provision of
  • Fit-for purpose performance testing environments.
  • Adequate application and infrastructure performance monitoring.
  • Data dependencies and requirements.
  • Appropriate credentials, licenses, and access.

Business Analysts:

• Dedicate real time and understanding to non-functional requirements. Understand what they are and why they’re important. Have these ready before design and development so that engineers can estimate accurately ad make the best choices around their system architecture.
• Research detailed metrics to inform detailed requirements. Vague non-functional requirements are pretty useless e.g. “Feature x should respond within 3 seconds”. Aim for “Feature x should respond within 3 seconds, while under a sustained load of 50,000 user sessions, at 520 requests per second”.
• Familiarise yourself with multiple sources of performance-related information. Even if you can’t capture the information yourself (e.g. raw log data) understand what to look for, and get somebody else to capture it.
  • Historical usage e.g. Marketing Analytics, Application Performance Monitoring, operational logs analysis.
  • Predicted usage e.g. Product Owners, business cases, usage reports, financial forecasts.

UX Designers:

• Research and understand the principals of front-end performance.
• Explore ways a designer can make an application ‘feel’ performant through clever use (or avoidance) of things like spinners, splash pages, skeleton images/icons etc.
• Consider the performance impact of the number of elements on a screen.
• Reduce image file sizes as much as possible
• Use clever design to draw attention to key parts of a page/feature, while background or off-screen elements can continue to load unnoticed.

The Mission

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.