Here is my view what’s valued in software engineering, it’s crisp and it helps me gauging my impact. So here it is – you are valued when you either create value or reduce risk. Feature teams obviously create value by coding up the features that end users use and happily pay money for. As a performance engineer I am in the risk end of the house. I help identifying risk of having inadequate performance and scalability of the product. Bad performance leads to poor user experience, loss of trust in product, and ultimately lost sales or extra cost to keep the original promise. No matter how great the features are, if it’s pain to use them then they are worthless, no value.
Your App is Broken and Here is how To Fix It
One thing is to identify the risk another thing is to find out the culprit of the risk, but what’s more is to suggest how to mitigate the risk. Having this in mind the valuable outcome of the performance testing could come out as a set of bugs with the following structure:
- Problem. This what’s being observed, something that is manifested during the perf test. Examples: “Response time of the page X is 15 seconds”, “The system consumes above 75% CPU under half of the target load”, “Memory consumption is growing in sustained manner.”
- Impact. This is why the observed problem matters. It helps when prioritizing one bug over another. Examples: “Breaking response time SLA”, “Lack of capacity for target load”, “Low reliability and continuous failures.”
- Culprit. This is the trickiest part, but most valuable. This requires skills and experience. This is most valuable since it gives an idea to the engineering team about what part of the code needs to be reworked – this may be tough task at a times especially in highly distributed complex systems. Look at the related materials below for some examples.
- Solution. This is where specific solution suggested so that engineering team can grab and run with it. It’s not generic guideline such as “apply caching” rather specific code snippet or pointer to a sample.
Using this pattern three goals achieved:
- Shorter bug resolution times since engineering doesn’t need to spend time on analysis and conceptualizing the solution.
- Chance of the bug to be resolved much higher and risk to be actually reduced as a result.
- Trust between perf and engineering teams is strengthened. Perf team is considered a contributor and problem solver vs. party pooper.