Focus on performance is an integral part of our software development life cycle. All development teams are required to consider performance from the inception of an idea through all subsequent steps including production.

This involves defining performance requirements, designing and coding with performance in mind, and preventing regression. Several tools are available to our teams, like documented coding standards, a best practices cookbook, and a support team with performance experts. Our QA approach is risk-based.

Technical and business risks are assessed for any code change. If a performance regression risk is identified, the team decides how to mitigate it, for example by creating an automated test. Automated performance regression tests run daily on the latest build. These tests run on dedicated infrastructure so that the results do not suffer from variations in CPU, memory resources, network bandwidth, and the like. If a test detects a deterioration in performance, the responsible team will analyze and take appropriate action.

When initiating a project, introducing a new feature, or exploring a customer idea, taking into account the performance aspects of making such changes is considered essential. Performance can play a big part in a customer’s experience and use of a system.

When considering a new solution, both functional aspects and performance requirements are explicitly defined. These requirements encompass not only the system's response time or the speed at which it returns a value but also account for the expected volume and size of the dataset deemed ‘normal’ usage by the customer during development.

Performance requirements and risks are discussed in collaborative sessions, involving representatives from development, testing, and typically the product owners. These sessions serve as a pivotal platform for aligning understanding and expectations across teams. 

After establishing the performance requirements and risks, the development team creates functional and technical designs. The outcome of the previous phase allows the team to collectively evaluate the technical implications of these requirements. Devising strategies to optimize performance without compromising functionality.

By openly addressing performance requirements within our “three amigos” sessions, teams can work to establish thresholds and limits that serve as guardrails against potential performance pitfalls.

These limits help prevent inadvertent design decisions or implementations that could lead to scalability issues or performance bottlenecks down the line. The technical designs are reviewed by our architects.

Once development starts, it is considered crucial for all developers to conscientiously consider the performance implications of the code they write. Where feasible, developers proactively implement (agreed) limits within the system to pre-empt any potential future performance bottlenecks.

To help aid developers in creating performant code, performance engineering guidelines are available to them. In addition, developers can apply specific tools to measure and inspect code performance. When a developer needs to have his code interact with the database, methods of a specialized database toolbox can be used.

This toolbox ensures high-quality code that adheres to our coding standards. Once the code is created, it is subject to peer review. If new code for database queries needs to be written, the code is also reviewed by a database administrator (DBA).

The testing phase extends beyond just ensuring the functionality of the software meets the required standards; it also includes validating its performance. Performance testing is incorporated into our testing strategies, as it is essential for delivering software that not only works but also performs optimally.

All teams have had extensive training in performance engineering and testing. When a performance risk is identified, the team will define an approach to tackle this risk. An entire range of techniques and tools are available.

To ensure that newer versions of our software stack do not result in deteriorated performance, we have a set of performance regression tests that run daily on the latest code base. Only after all the risks are mitigated, is a team allowed to release new software into our base trunk. 

Performance depends on many factors that are comparable between customer environments, like the hardware and infrastructure, while other factors vary a lot, like all functional configurations and the amount of database records.

As Planon is highly configurable, the number of possibilities is endless. We will never be able to predict, let alone test all possible configurations. Performance issues in production cannot be prevented 100%. We continuously monitor the availability and performance of our cloud environments and take proactive precautions.