Performance is a requirement

Most of the times as software engineers we are getting requirements that describe the functional scope of a feature. The tickets that we are working on usually look something like:

As a user I want to be able to create an account by entering a name and an optional address so that I can start playing the game.

The ticket does not describe the non-functional requirements of the feature. For example, it is a completely different experience if the user is able to type her name quickly versus facing some short of lag:

Fast IO:

Input with 30ms lag

Slow IO:
Input with 500ms lag

Performance is a requirement that is unstated, it is up to us to have a mindset that makes the implicit requirement for performance and responsive applications, and make it more explicit.

For example, imagine that you were asked to create a view to display a list of products to the user, and the only displayed information is the name of the product. Of course, the call to your database could be:

SELECT * FROM products;
Time: 287.726 ms

You take everything from the table of products and in your UI you display only title. Sure, this works, and your Product Manager would be happy for a while, till more and more fields are added to the products table and the page starts feeling less responsive and more slow. But what if you only get the attributes that you need?

SELECT title FROM products;
Time: 80.663 ms

Personally I believe that is our responsibility as software engineers to:

  • Find easy/small performance wins

Does our use case need an accurate response, or can we serve the user with an approximation? Does it worth to spend the time do to a computationally expensive task or is ok for example to serve cached data?

  • Raise red flags when we see designs that may affect the performance of a user task

The designer came up with a fancy design that requires rendering a list in the view but they are not aware that we have thousands of records stored that we would need to render. In my opinion in cases like that is our responsibility to raise red flags and even propose solutions e.g. pagination or fetch records as the user scrolls the page.

  • Define clear performance requirements for user stories

Many times Product Managers are not having a technical background, even if the story states “I want the list to load fast”, that is not a clear requirement for a software engineer, what is fast for me may not be fast for someone with a slow internet connection that lives in India. It’s our responsibility to define more tangible requirements.

  • Continuously monitoring the performance of our apps

We should define our performance budges, continuously monitor and take actions when the performance is not aligned with our standards.

Next time your Product Owner/Manager came up with a feature request, question (yourself or them) about the performance requirements/impacts of the requested feature.

Published 21 Aug 2019

Software Engineering Lead, Certified AWS Solutions Architect. Opinions are my own and not necessarily the views of my employer.
Avraam Mavridis on Twitter