Why am i writing this article: Working on projects at different client locations, it’s not un-usual for me to find that we tend to want to re-inventing the wheel time and again. Over the last decade I have had the opportunity to work at some of the largest organizations around the world and the one sad thing (can assure you that there are numerous good things as well) that i keep encountering time and again is the fact that most programs I have worked on have no Non Functional Requirements or such poorly defined Non Functional Requirements that it makes validating overall system performance or end user experience an uphill task. Frankly if there are no SLA’s or Non Functional Requirements to build against then how do you validate the quality of what’s beign delivered. Unfortunately most customers, Technical Architects, Program Managers, etc. view Performance from their rose tinted glasses and assume that having an experienced Performance Tester on board at the end of build phase is enough to address their performance and capacity woes. Every time i think about this and visualize the amount of time, energy and resources that will be spent by organizations around the world trying to retrofit performance into the application at the end of the program product my stomach cringes and i feel despair setting in.

Continue reading Non Functional Requirements & It's Importance Across the SDLC

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.”

Continue reading Don't Sell Yourself Short

So what is it about Software Performance Engineering that gets us so excited. What is the buzz all about and why should you as a Practical Performance Analyst get exicted about the work we are doing. Let’s start off by taking a look at what Software Performance Engineering stands for including the roles played by a Practical Performance Analyst within the Performance Engineering team across an enterprise. We will then move onto some of reasons why we think a career as a Systems Performance Engineer is truly challenging and ultimately fulfilling.

Continue reading Six Reasons Why You Want To Be A Systems Performance Engineer

Introduction - Working as part of delivery teams building, validating and delivering systems into production I quite appreciate the insight modelling tools provide and what one can achieve using that kind of insight. Understanding the various modelling techniques and knowing how to apply them allows for greater insight into the behavior of complex systems. Such insight gained can help with validation of sizing assumptions, un-realistic non-functional requirements and end user service level agreements (SLA’s) that the program might never be able to deliver on. Having the ability so pull together a few fundamentals equations to validate these critical assumptions at the design stage will save everyone a lot of trouble down the line.

Continue reading Understanding System Constraints

The conundrum - Numerous times in my career I have encountered situations where clients demand engineering skills but are reluctant to pay for those niche skills. Clients expect to pay rates for a skilled Performance Testing resource but instead expect a seasoned Performance Engineering resource and it does take a while to communicate to the client the subtle difference between the two including the outcomes each of them are skilled to deliver. Smart clients who understand the difference in value proposition consider investing in the niche engineering skills they might require to get the job done.

Continue reading Do You Have What It Takes