A few months ago, the famous Ticketmaster website crashed and could not sell Taylor Swift's Eras tour tickets. Customers were very frustrated, and businesses involved lost millions in revenue.
A closer look behind the scenes uncovered that the high demand for Taylor Swift's tickets pushed the system to its limits until the site was no longer responsive.
The lesson learned that day is:
We must create performance requirements.
We must revisit our performance requirements.
We must Stress Test our platform frequently.
Sadly but true, too many businesses ignore the importance of performance requirements and focus their efforts entirely on building the next big thing. As a result, they realize massive problems after launching IT services on production when new business applications do not fulfill customers' user experience requirements.
Consequences of weak performance requirements
We are often so tight up in our features and oversee how our customers use the end products. The best outcomes are worth nothing if they do not match a consumer's performance expectations. A slow but outstanding feature won't make your customer happy. It's simply the wrong product.
Waste your budget. From an economic standpoint, it's better to skip the entire performance test than spend person-days implementing tests based on vague requirements. For example, let's imagine that according to your NFRs, a system will be used by 300 concurrent users, and there are 300.000 transactions per hour. This massive transaction volume requires services that are designed for high performance. Tuning for high speed is expensive and a waste of money if usage volumes are unrealistic for your application.
Frustrated customers. Research has shown that customers are more likely to return after they experience an outage than after performance slowdowns. Slow loading applications destroy your reputation as a trustworthy provider. Whether you are developing systems for your employees or external customers, they will abandon using your services if performance is not within their expectations.
Massive firefighting. Nobody realized that performance was neglected during the whole software development phase. Several hours after deployment of your brand new system on production, severe issues occur. The operational team fallback to their default - lets restart procedure - and restart all services. The same trial and error scenario is continuous for a couple of hours. Business starts their escalation to IT management, and the hunt for the responsible engineer is on its way. Such situations are a daily business in many organizations. Their problem started on day one with neglected NFRs, but it will take them several times more to fix it in the firefighting mode.
A better way to avoid all mentioned nightmares is the creation of meaningful and correct performance requirements. If you have ever worked in a business analyst position, you might know that there is typically not much information on HOW the new software needs to provide intended services.
Keep up the excellent work! Happy performance engineering!