By Kavitha Mariappan, director of product marketing, Riverbed
General George S. Patton said “Do not make excuses, whether it’s your fault or not.” Unfortunately when performance issues arise with Web applications, some developers and IT admins don’t heed this advice. They immediately deflect blame, particularly when errors involve customers or lead to revenue loss.
Take for instance the launch of a new e-commerce website flush with new software and a revamped, multimedia content strategy. This is an exciting time for any company and all eyes are on the results. However, failure to plan for and execute on this new strategy appropriately can actually cost the company sales. Your executives are now angry and the finger-pointing at IT ensues. How do you handle it?
There are constructive and not-so-constructive ways to deal with the aftermath of speed and performance errors on the Web. No matter who is at fault, you and your execs all want the same thing: whenever possible, avoid web performance problems altogether by taking proactive measures. If you can’t, then rather than look defensive it’s best to focus on the fix. Here are some familiar yet unconvincing excuses for performance hiccups that, as a developer, you’d be wise to avoid.
1. “I don’t write slow code.” Talented developers are a hot commodity, but guess what? Mistakes happen and performance issues aren’t usually about bad code. There are configuration issues, integration issues, network issues, and countless other reasons why websites aren’t running fast. This is where it helps to have analytics and data to show exactly what is causing the most delay.
2. “We’ve already performance-tested the application.” Performance testing is highly subjective. It’s kind of like the kid who says he cleaned his room, but instead simply stashed all his dirty clothes under the bed. You need to take performance testing all the way and that means simulating real-world scenarios and unpredictable change, such as large spikes in traffic during typically slow periods of the day. That’s why it’s smart to use third parties for application testing because their job is to look proactively for failures and gaps in your systems. It’s also a best practice to operationalize performance testing and incorporate it into ongoing administration practices. That’s the premise of DevOps: continuously managing change.
3. “It’s fast on my machine.” Developers tend to live in a (high-performance) bubble. Users typically aren’t on the latest hardware and generally have slower Internet connections. Case in point: A while back we benchmarked the website performance for a group of top public companies in the US and UK. One of the UK companies, a trucking company, had one of the worst-performing websites. When they balked, claiming the site “is plenty fast for us here,” we discovered that they had a 5MB video on their homepage that was super slow to load for users outside their network. It’s useful to remember the age-old saying: “You are not your customer.”
4. “We’ll fix it post production.” When you’re trying to meet a deadline, it’s all too easy to make performance an afterthought. Performance is as critical as all the features that you’re working to perfect. Releasing your new application or website without making sure it works well for users is like showing up late on a first date: You’re not putting your best foot forward. Deal with performance issues when they come up, not when users are unhappy and revenue is at risk.
5. “We have a new launch coming that fixes performance.” This is delusional thinking at its finest. It’s rare that a new version of a website or application will fix your old problems. The same issues or new ones usually crop up. Again, make performance optimization part of the continual process of application development and upgrades.
6. “Your network/hardware is slow.” How many times have you been on a tech support call and they ask for your system specs and what type of Internet connection you’re using? The fact is those things usually aren’t the problem. Remember the Performance Golden Rule which shows that 80 percent of the time it takes to download and view a website is controlled by the front-end structure, not the network.
7. “It’s the platform’s fault!” Techies love to bash the platform or another vendor for performance problems. But there’s always something you can fix in your own environment to improve performance. And that’s usually easier and more effective than calling the big vendor or bashing them on Twitter.
Webpages will continue to become richer and more complex. In parallel your customers will continue to demand better and better performance and availability – it’s inevitable, but how you handle these situations will make all the difference in how executives perceive your IT department moving forward. General Patton made it clear that there was no room for excuses among his troops; he also told them “Do not fear failure.” Both are wise words to live by when it comes to implementing Web strategies that will differentiate your company and drive revenue.