Let’s get introduced - Do you remember the last time you had to explain to someone what you do for a living? Do you remember your conversation with the recruiter trying to explain what you do for a living? Do you remember the last time you tried to explain to your mum what you do for a living? For anyone who has been engineering systems and working in the performance space for over a decade this is a scenario that’ss all too familiar. You meet up with a colleague over a coffee and are trying to explain what you do for a living and you end up getting asked the question, “What do you do for a living”…and your response goes something like this….”Have you heard of Performance Testing? Performance Testing is part of what I do for a living a small part of it. However, I work with customers and help them manage Performance and Capacity of their applications. The space i work in is called Systems Performance Engineering and my role as the lead Performance Architect on the program is to ensure that we design, build, test and deliver systems that are engineered to scale, meet the agreed Non Functional Requirements.”

This article was originally published on 2012-07-10 at the original Practical Performance Analyst website.

These are generally the words I end up using when I introduce myself to people who have little understanding of my profession or Performance in general. Of course there’s nothing wrong with not having an understanding of Performance Engineering, what does at times irk me is that the Engineering in Performance Engineering gets confused with the Testing from Performance Testing space. Having said that, going into murky depths of Performance Engineering over the initial coffee might be considered a taboo and possibly a conversation non-starter, given the technicalities involved. Many a times i end up using the analogy of a racing car engineer who’s primary responsibility within the engineering lab is to design, build the fastest, lightest and safest car to beat everyone else on the track. Once the car leaves the confines of the design lab the racing performance engineer then works with the pit crew to constantly monitor and tune the hundreds of performance parameters from the car to deliver optimal performance for the given race track conditions. Very similar to what a Systems Performance Engineer would be expected to do in his or her role delivering systems that scale and meet the agreed Non Functional Requirements.

The situation does not seem to get any better even when I visit vendor (performance tool related) conferences which I have stopped going to simply cause I tend to take away very little from it other than it being an opportunity to experience the ambiance and possibly sampling a few of the eats on offer. Vendor conferences tend to be product show cases for all the die hard product fans. These conferences tend to be great opportunities for product fans to get together and claim their product is the next best thing after slices bread and and that’s how it’s mostly been. Try this next time you go to a vendor conference (related to Performance) and tell me what you come up with. Ask the people beside you if what they do for a living, try explaining what you do for a living and come and tell me about your experiences.

Do customers really care - A Performance Engineer (I used to be one) by profession I have realized that most customers i work with start off having very little or no appreciation for what I do, most do not understand the concepts of Performance Engineering and possibly do not want to be bothered understanding the real meaning…:). However, most of the customers I have worked deep down wants to ensure that the systems being delivered meet their Non Functional Requirements. That’s essentially what really matters and I use that as an opportunity to educate them on the importance of investing in Performance Engineering as a risk mitigation strategy. I take a lot of effort in educating my customers, that an investment in Performance Engineering is an investment in proactive Performance Management and is their only way of ensuring that their application performance does not go pear shaped in production.

Customers do want their applications to scale in production and every customer wants their systems to support their growing business workload. The best way I have found to create appreciation for the work a Performance Engineer does is to help customers articulate their Non Functional Requirements, paint a picture of the challenges that need to be addressed for the program to deliver the expected business benefits and articulate clearly the impact of not meeting the given Non Functional Requirements from a business standpoint. Once customers have understood that a risk mitigation approach exists and that one could proactively address Performance across the Software Development Life Cycle, Performance Engineering becomes an easy sell.

The bottom line is most customers do not understand Performance Engineering, but they do really care about their investment in the applications being delivered and are willing to invest in the vision of Proactive Performance that you paint for them.

Proactive Performance across the SDLC - As a Performance Engineer would keep advocating an investment in performance across the Software Development Life Cycle. There is obviously nothing new about this and I do not intend on preaching to the converted simply because every one of you reading this article probably understands the need to do so. However, the understanding of the tasks across the SDLC involved in delivering Performance is barely understood and this is where things start getting hazy. Performance Testing is an integral part of Performance Engineering and a very small part of Proactive Performance Management. Proactive Performance Management requires you to address Performance proactively across the Software Development Life Cycle and this includes the following set of high level tasks (See the Fundamentals section for text based tutorials on the various Performance Engineering related sub processes and Video Tutorials for more in depth tutorials):

• Performance Requirements Gathering
• Design for Performance, Capacity Planning & Performance Modelling
• Build Optimization & Performance Tuning
• Performance Testing & Optimization
• Performance Monitoring
• On-going Capacity Management

There are a lot of organizations out there focused on selling Performance Testing services to the client and yes that is absolutely great. But, if you have done your bit selling only Performance Testing services to the client without educating them on the need to invest in Proactive Performance Management across the Software Development Life Cycle you have done your profession a complete dis-service. Investing in Performance Testing before go-live is a sure way of identifying bottlenecks that exist in the application after the client has spent months if not years building those bottlenecks into the application. What if you were slightly more proactive and saw the opportunity to work with the client in addressing the bottlenecks early on in the SDLC. You would have helped the customer save on potential re-work due later on during Performance Test; you would have created a larger opportunity for yourself and would have helped the client gain a better appreciation for Performance Engineering in general.

Proactive Performance Management pays, it pays the customer back by reducing overall development costs and definitely pays off for you by increasing your overall revenue from a services standpoint.

How we shoot ourselves in the foot - Performance Engineering is no rocket science. However, the awareness of Performance Engineering and its adoption across customers worldwide is really low. Most Performance Testing Engineers I have met can barely define the concept of workload leave alone build a workload model using Littles Law to reflect a true scenario of users accessing the application concurrently in production, or understand the inverse relationship between response times (total service time) v/s transactional throughput (bandwidth). But then I argue, isn’t this a situation we have brought upon ourselves?

Have not we got ourselves into a situation where complete lack of standards means individuals and organizations who have an understanding of Performance Engineering are doing very little if not nothing to educate the community and create awareness of the processes, tools and capability required to address performance proactively across the Software Development Life Cycle. The few organizations that champion the cause of Performance & Capacity Management do so in isolation without taking the initiative to build an open Body of Knowledge that the rest of the world can access. Performance Engineering remains the domain of the chosen few and that has to change.

I argue that we tend to shoot ourselves in the foot, we tend to sell ourselves short when all we do is sell Performance Testing services to our customers. What we have essentially told our customers is, go ahead, bake all the performance bottlenecks, infrastructure bottlenecks and architectural constraints into your applications and definitely do not spend any time defining your Non Functional Requirements. I will come in just before go live, performance test your applications and work with you in tuning your application with the hope that we can help you save face and possibly resurrect your application performance to such an extent that you will not get fired.

Be proactive, use Performance Testing as a starting point for the conversation and educate the customer on the benefits of Proactive Performance Management. You will end up creating more opportunities for your business.

The early bird gets the worm - It is amazing to see that technology has evolved to simplify most tasks for us from a software development, build and test standpoint. However Performance Engineering is one of the most neglected subjects in Software Engineering. The lack of industry standards, prohibitive costs of performance engineering related tools, the complete lack of educational material, the lack of professional forums to educate budding Performance Engineers, complete lack of a Body of Knowledge and the lack of skills just go to create more confusion than anything else.

I see this as a great opportunity, I see this as a great opportunity for your business, I see this as a great opportunity for your career, I see this as a great opportunity where you can help your customers grow their business while helping them appreciate what Performance Engineering has to offer. We definitely have a long way to go. And the day you start selling yourself as a Performance Engineering business which also has Performance Testing skills, the world would have taken another stride in the right direction.

Hope you have enjoyed this piece here at Practical Performance Analyst. Drop us a note with your comments, inputs and feedback at trevor at practical performance analyst dot com. If you are interested in learning the fundamentals of Systems Performance Engineering please head over to the SPE Fundamentals section to learn more about the fundamental equations and strengthen your understanding of the various SPE related concepts.

Drop us a note if you have any questions, comments or input.