Web Performance Calendar

The speed geek's favorite time of year
2021 Edition
ABOUT THE AUTHOR

Alex Podelko (@apodelko) has specialized in performance since 1997. Currently he is a staff performance engineer at MongoDB, responsible for performance testing and optimization of the MongoDB server. Before joining MongoDB, he worked for Oracle/Hyperion, Aetna, and Intel.

Alex periodically talks and writes about performance-related topics, advocating tearing down silo walls between different groups of performance professionals. His collection of performance-related links and documents (including his recent articles and presentations) can be found at alexanderpodelko.com. Alex currently serves as a director for the Computer Measurement Group (CMG), an organization of performance and capacity planning professionals.

One of the questions I am periodically asked is about presenting a business case for performance. It is rather a tricky question that may have many layers in it. While there is no generic answer, here are some building blocks.

Original Approach

In the beginning, during the mainframe era, it was rather easy to present a business case for performance. Mainframe resources cost so much, so every improvement usually paid off efforts multi-fold.

Then we got to distributed systems and it became more difficult to make such a case. Here is an interesting quote:

“Fix-it-later was a viable approach in the 1970s, but today the original promises no longer hold, and fix-it-later is archaic and dangerous. The original premises were:

  • Performance problems are rare.
  • Hardware is fast and inexpensive.
  • It’s too expensive to build responsive software.
  • You can tune software later, if necessary.”

When do you think it was written? Well, at least the book Performance Engineering of Software Systems by Connie Smith was published in 1990. It still sounds up to date for me. Except that today many people say that “fix-it-later” (which nowadays has several fancy names) is the best approach (which may be true in some – but definitely not all – cases, which is a completely separate discussion).

You may check a great collection of more generic references for a business case for Software Performance Engineering by Connie Smith. Of course, even then it was stressed that there are many intangible benefits of performance – up to improving employees morale – but not many efforts were done to quantify them. If we talk about more recent discussions, you may check a nice write up about the business value discussion at the fourth Neotys PAC.

Actually, the rise of Cloud brought it back to original points (the charge back model when you pay for resources you use is very close to what was in the mainframe era). The sheer costs of cloud bills got some attention back to capacity planning and performance. Improving performance again has a clear price tag – even if we forgot about intangible benefits (which we shouldn’t). The FinOps movement is a clear indication of the trend. It appears that it tries to move it too much into the financial side away from engineering – but performance engineering could bring it to a completely new level.

Web Performance

With advances of web performance, there were numerous attempts to quantify cost of speed. The most prominent are probably the WPO Stats site: Case studies and experiments demonstrating the impact of web performance optimization (WPO) on user experience and business metrics and Tammy Everts’ Time is Money: The Business Value of Web Performance.

There were many great posts on the topic a few years ago – but I couldn’t find too many recent publications. The WPO Stats site gets updated. How Web Performance Affects Business Results (18 Case Studies) has several recent updates. But older posts are still mostly relevant. For example, Tammy Everts’ presentations Web Performance ROI: A Brief History, The Business Value of Web Performance, and The Real Cost of Slow Time vs Downtime.

It is great to see numerous studies quantifying the business value of performance. But a lot of them are related to very specific cases of Internet giants, so they may be not directly applicable to your case. Don’t apply all of these findings blindly – read Non-orthodox (renegade) rumblings on speed-money relationship by Alexander Podkopaev elaborating why. But looking through all that available information could make it easier to prepare your own business case for performance engineering.

Epic Failures / Outages

Another interesting genre for business value of performance is description of numerous epic failures and outages.

They basically happen every day. Listen, for example, to News of The Damned or check SRE Weekly. It appears that they became so common, so I don’t see many posts listing the most prominent failures recently. At some point there were quite a few of them – like 16 Website Crashes From 2017 That Could Have Been Prevented, 11 Costly Website Crashes and Application Performance Bloopers to Learn from, or Failing at scale: What I learned from 3 colossal software QA disasters.

Keep It Up to Date

It probably won’t hurt to present the value from a different angle – to connect it to most important issues of the day. Just posted in Performance Calendar A site’s carbon impact as part of #webperf! by Robin Osborne or Continuous Performance Testing for less Carbon footprint: A thought by Arun Kumar Dutta may be good examples here. Yes, performance is directly correlated with power consumption and carbon footprint – having additional social value on the top of power costs and cloud bills.

Summary

Unfortunately, in my experience, it is almost impossible to convince somebody of the necessity of performance engineering until they face real issues. Maybe somebody much more eloquent could – but I’m not sure. However, it usually doesn’t take long to run into performance-related issues of one kind or another – and then all the points mentioned above may help to promote performance engineering. Just use what is relevant to your domain and the issues at hand.