The first rule of Performance Engineering Fight Club is that you MUST talk about Performance Engineering Fight Club.

 

10. You refer to Performance as an NFR (Non-Functional Requirement).

Does your site rely on performance as a competitive advantage?

How is retaining your end-user with adequate performance not a core functional requirement of the site?

Performance is a function of deliberate design, science, hard work - and yet we call this an NFR?

Does your business de-prioritize Performance because it is an NFR and therefore does not have the gravity of a so-called Functional Requirement? Someone needs to join the Performance Engineering Fight Club.

9. You have no site performance attributes inside your user stories/requirements.

Take a look at Google RAIL as a practical starting point.

It stands to reason that if there is no standard of performance for your site that your entire product team is held to, then there should be no surprise when your users flee to sites that do have standards and work them seriously.

8. No one on the product development, test or production support teams can answer this question, "What is the expected response time for ______?"

See Above.

Performance is the responsibility of everyone on the product team.

Who is incentivized in your organization to champion Performance Engineering?

7. Do you measure your site performance in hits per second instead of response times?

Do your end-users care how many transactions per minute your site can process?

Do your end-users care about caching, static content delivery, edge-server configurations, or performant code?

No, they don't care, but they are the beneficiaries of all of these things.

There is no single measure to classify your entire site as being ready for prime time, but response times are among the absolutely essential measures to understand your end user's experience under load conditions.

6. The majority of your QA intellectual capital is designed by, held by, managed by off-shore resources.

Like the old Michelin tire ads telling us that, "The life of your family rides on Michelin tires" - If you can say that the cash flowing into your company rides on the performance of your applications, then you're in the right place, reading the right things.

Divesting your intellectual capital to external sources, be they on-shore or off-shore, partners or service providers, or SAAS relationships, the quality and performance of your applications are susceptible to many unfortunate side effects as a result - the least of which is having a domestic team that knows nothing about your testing infrastructure and cannot analyze or operate it.

5. Your marketing team celebrates your site being crashed due to high demand and sees it as a badge of honor and street cred in "the bizz."

This is a form of self-imposed corporate Schadenfreude, delighting in the misfortune of yourself!

If Marketing celebrates your site crashing, why are they still working for your company? Marketing should own the responsibility of informing operations, QA, development, and all interested parties what the projected user loads of their campaigns will look like. This is a requirement. Why are you allowing Marketing to sabotage your brand?

4. You purge your server logs without reviewing them.

Your server logs are the "black box" of your systems. The logs contain the fingerprints of the events that led up to your last site disaster. Not retaining and analyzing these logs is neglectful. Employ tools like Splunk to automatically grab, parse and index them for quick decision making.

Implement Splunk now. Before you lose another opportunity to harvest the big red flashing arrows that point to your server performance problems.

3. Your development team treats the web browser like it is a thick client.

Pushing massive payloads to the web browser is a serious tactical mistake that is being made by countless companies today.

Business logic and rich UI top the sins committed in this way - with massive JSON payloads, huge image files, static content, and more.

So you know, this shift from nimble, performant front-end browser representation makes your site almost un-testable. Reverse this trend immediately, and start considering that every byte that you push to the browser, every millisecond that the user has in latency, these things add up, compound upon each other, and ultimately are the sword that your organization will fall upon when your site is pushed by a business event.

2. Your end-users have a less than stellar experience and let your competitors know, with their dollars.

If you lose conversions because of poor site performance, who feels that pain?

If your users flee your site during a publicized event, you lost the sales, but you also gained something - negative notoriety. Your site is now being talked about as being incapable of fulfilling the promises you made to your potential customers when you wooed them to your site with promises of fulfilling their wishes. How much does that cost your organization over time?

1. Your site still crashes during business critical events.

"Fool me once, shame on me." This is what CIO's should say if their site crashes because there is no excuse in 2019 for businesses to push product into production with only a hope that it will work as required.

Don't put off joining Performance Engineering Fight Club any longer. Your business can't afford it. Call Foulk Consulting TODAY at 888.908.1613

Many thanks to James Pulley, The Perfbytes News Of The Damned, and the entire PerfBytes team who served as the inspiration for many of these points.

 

BONUS ENTRANCE CRITERIA

- Your developers treat RAM, CPU, and Network as infinite resources

- Your team is celebrating that the homepage load time went down from 2 minutes to 30 seconds and count that as “done”

- Your team chooses to ignore 404 errors in production and treats them as somebody else’s problem

- You don't understand why your site is calling 3rd party sites during load and performance testing

- Your marketing team is implementing 3rd party content on the site and is not involved in performance related discussions

- Your marketing team can control 3rd party content on the production site, dynamically without Dev, QA, or OPs knowing anything about it

- Your site thumbnail images are actually hi-res images being re-sized with CSS magic

- Your old products are never removed from the production database

-  You have an extensive test array. You have automated test suites. You're running testing through pipelines. You're shifted-left as far as possible. You're shifted-right as far as possible. Your creation produces volumes of web page reports and data ... and it all tells you absolutely nothing about what you need to know about how your site will perform when you need it to. (See #1)

- Your developers fall back to "autoscaling" or larger hardware to solve performance issues

- You don't know how much of your client load originates in a cloud provider data center