Performance engineering

Performance engineering: What it is and why your team needs it

Performance issues don't just happen; they're designed into the software. That's not because software engineers are malicious—it's because they're human. They make reasonable assumptions about the software they write, and that's where they stumble.

How sure can you be about those assumptions? Do you have any idea how your system will perform and where the bottlenecks will turn up before coding starts? Performance engineering best practices can keep you sure-footed as you travel down the software delivery path.

Why you need performance engineering

Software engineers have been stumbling over invalid assumptions since the dawn of computer programming. Consider, for example, an airline ticketing system. Ten years ago, airlines offered limited online services or none at all. You could search for flights and purchase tickets, but only if you were using the right browser.

Today, everything is more complicated. In addition to buying a ticket, you can check in, select a seat, choose a meal, pay for additional baggage, manage your frequent flyer account, and so on. Developers must support all major browsers, including mobile, as well as develop mobile apps. Then there's the software that drives the check-in kiosks at the terminal and dedicated apps for the ground and flight crews.

All of these new features and computing environments have to work with legacy back-end code designed to manage the system as the world existed ten years ago. They also have to meet the performance requirements of today.

So how do you avoid performance issues without assuming too much about what lies ahead? The classic approach is to include load testing as an integral part of the quality assurance (QA) cycle. However, by the time the app gets to QA, it's too late. Not only have you invested a lot of time and effort into the design and development process, but the business needs the app ASAP. If you wait until the last minute to find a fundamental performance problem, it will delay time to market. These days, the business isn't willing to wait for your team to get it right a second time around: You need to get it right the first time. Only by adopting a performance engineering mindset can you ensure rapid application delivery.

Performance engineering methodologies align perfectly with agile processes, taking a "shift-left" approach to address performance much earlier in the development process. For example, component coupling is one of the main causes of performance bottlenecks. When components depend on each other, the overall system performance is limited by the slowest component, the weakest link in the chain. By decoupling system components by design, you can optimize overall system performance.

That might mean changing a system from synchronous to asynchronous communication with the user. This way, the user doesn't have to wait for a synchronous response while the system completes a transaction on the back end. Instead, the user is instantly informed that a response will be sent, asynchronously, by email. In this case, the user may very well perceive the change is providing better performance.

It's no longer enough for developers to write bug-free code. Immediately after they run the debugger on new code for the last time, developers should run profilers to ensure that the code they're committing performs as well as possible. During the integration phase, the newly combined codebase must undergo performance testing to ensure that all commits work optimally together. Performance engineering is a more comprehensive approach to optimization than just conducting simple load tests at the end of the development phase.

The four Ws of performance engineering

Here are the four Ws to consider in performance engineering and a breakdown of how they compare to performance testing.

Why: We use performance testing to simulate how a system will perform under production loads and to anticipate issues that might arise during heavy load conditions. Performance engineering is driven by business requirements. The aim is to provide better business value for the organization by discovering potential issues early in the development cycle. The cost of fixing a bug increases in orders of magnitude as you move down the line from the design phase to production. So why wait?

What: Performance testing simulates production loads to detect potential performance bottlenecks. Engineers following performance engineering methodologies optimize the application for performance from the earliest design stages.

When: Performance testing is a distinctive QA process that occurs once a round of development is completed, while performance engineering is an ongoing process that occurs through all phases of the development cycle, from the design phase, to development, to QA.

Who: Dedicated QA teams execute performance testing. In contrast, because performance engineering occurs throughout the development cycle, everyone takes part. This approach ensures that by the time the system gets to QA, it's already in an optimized state. The responsibility for performance starts with software designers and system architects, extends to the developers who do the coding, and ends with QA.

Performance engineering produces great return on investment for two reasons: It reduces the need to rework and refactor the application in later development cycles, and it results in an application that performs better precisely because performance was an early consideration and an integral part of the design.

As a result of the move to performance engineering, the classic roles that different engineers play in the software development cycle have blurred. Whether you are a designer, a coder, or a QA tester, system performance is now your responsibility.

Topics: QualityDevOps