Arguing about software performance is a highly traditional software developer pastime. On the internet, we can find developers criticizing certain programming languages, frameworks, design paradigms, libraries, etc., for their poor performance. Complaints about the poor performance of current software (e.g., Microsoft Teams, Slack, Jira, ServiceNow, Microsoft Visual Studio, and many others) have also become quite common over the past years. While I understand the frustration and I’m not fond of many current software products as well, I think that this whole debate is fruitless because it misses the point.

First of all, we need to keep in mind that it’s impossible to predict software performance in a vacuum. There are so many moving parts in any current software stack that we have to actually measure the performance to find out which approach is faster. Intuitively guessing about performance is not reliable and can lead us in the wrong direction. This is described in detail in “The Art of Writing Efficient Programs” by Fedor Pikus. Hence, all these performance discussions are pointless. It’s just not possible to state with certainty, for example, that framework X will always be faster than framework Y or that garbage collection is always slow. People who make these kinds of statements are misguided.

More importantly, there is no evidence that high-performance software is desired by end users. Of course, people will claim to prefer fast software similar to how they will claim to prefer secure software. However, this stated preference isn’t visible in their purchase decisions. There are a lot of very successful slow software products on the market today, and there is very little customer pushback to their poor performance. Microsoft Teams is a great example of a slow (and in my opinion quite terrible) software product that is immensely successful. Granted, a big part of this success is Microsoft’s ability to just bundle it with other products to get it into the market, but it’s still a great success nevertheless. Jira is another great example. It’s the de facto standard for bug tracking with an estimated market share of 86%, even though it’s quite notorious for being slow. If customers actually valued performance highly, there would be a competitor with a “turbo Jira” product taking the market by storm.

This phenomenon is not limited to enterprise software. Even in video games where high-performance programming has a long history and where high frame rates are considered highly important, we don’t see significant customer pushback to poor performance. It’s well known that games are less optimized for best performance today than they were in the past. However, this doesn’t mean that poorly optimized games also sell poorly. For example, “Cyberpunk 2077”, which was so poorly optimized on launch that it was removed from Sony’s PlayStation store, still sold more than 30 million copies. People might complain about poor performance, but they will still buy the product.

So, what does this all mean? Sadly, it means that spending a lot of effort to create high-performance software doesn’t pay off. While there are some cases where high performance is a hard requirement, for example, in a high-frequency trading software, in general we don’t see a big demand for fast software. People just value different qualities more. As we only have a limited amount of time and money to invest into a piece of software, we probably should focus on different aspects rather than on performance. My recommendation is to build the software in the simplest way possible and then to check whether we have any performance issues. This minimizes complexity and allows us to get things done quickly. It’s an optimistic approach that assumes that we’re unlikely to encounter any serious performance issue and that we will be able to solve them if we do. Nevertheless, it pays to keep performance in mind when designing the application. For example, we should design our UIs in a way that limits the amount of read data. Let’s assume that we’re building a stock broker application. It makes a lot of sense to only display any trades done in the last month by default, as displaying all trades at once could lead to poor performance. If we keep this in mind, we should at least achieve acceptable performance. We’re lucky that today’s technology allows us to get away with an optimistic approach.

Conclusion

If we look at the software market today, we can clearly see that customers don’t buy a product just because it offers better performance than other comparable software. Hence, it’s rational to prioritize software performance less during the development process.

If you liked this blog post, please share it with somebody. You can also follow me on Twitter/X.