As I mentioned to recently on Twitter, there is a problem of identity crisis within the Application Performance community. One that others have touched on in the past but still seems prevalent.

If you are sick you don’t to go a “Healthcare technician” or a “medical analyst”, you go see a Physician. People work towards this title as a career goal because it is well defined and respected. But what about us? What do we aspire towards? Heck, what do we even call ourselves?

  • Performance Testers
  • Performance Analysts
  • Automation something-or-other…? *shudder*

Perhaps the answer seems obvious to you, and if it is then congratulations for not having the identity crisis that myself and many people I have spoken to seem to share. However this goes beyond standardizing on a name for people with the right skill set, although I believe that would help.

Part of the issue may stem from IT organizations not knowing where to put people like us. I have personally reported into Quality Assurance, Development, Operations and Support, all the while doing the same job. I can’t tell you how many people I have talked to with similar experiences, where the role is the same but the title and reporting structure are always different.

You may choose to call yourself a “Performance Tester” or “Analyst” because that is the title given to you by your current employer, but these fail to capture the entire scope and path of anyone focused on performance as a career. “Performance Engineer” has a nice ring to it, and I’m sure many would like to call themselves an Engineer, but this presents a problem. Are we really engineering application performance? I would estimate that only a select few have the background and experience to call themselves Engineers in this regard. Even more troubling is that there are a great many who throw titles like this onto their resume and don’t have the skills to support it, which brings down the value of the profession for others.

This is all very similar to the commoditization of Java Developers in the early 2Ks, when it seemed all the rage to farm jobs to low cost centers and the average wage of programmers dropped sharply. To executives, a programmer was a programmer was a programmer and it made sense to find the best deal possible. But the low cost centers struggled to retain skilled talent as the pressure of double-digit salary growth forced high attrition rates, and quality suffered. I know this is still the case in many areas, as the low cost centers of 2005 are now sending jobs to other low cost centers, where wages are rising, etc, etc…

The upside to this effect is that wages are on the rise again, and the App Explosion has renewed the once illustrious status of the “Application Developer” as a source of innovation and value to the business.

I also believe standardized education is an issue. In a Computer Science degree you are guaranteed to cover the basics of machine language, data structures, compiled and interpreted languages and a smidgeon of business (or more, depending on where you attend). Somewhere in there you may learn about how to build secure applications, and maybe even scalable ones, but there is no specific training for Application Performance Engineering that I have seen used as a standard for the profession. Did I just call it APE? Really?!

Anyways… we really need to start by defining what core skills are required to make someone successful in this field, and build a standard curriculum around that. Maybe then we will have a title we can agree on as the pinnacle, one that people will aspire towards and IT organizations will define a place for, much like App Security teams have experienced in the last several years.

Finally, what would that place be? Should Performance Engineering be a unique entity with a C-level position reporting directly to the CIO/CTO? Probably not (although it is a nice thought). Unlike Information Security, which until recently also tended to be shuffled around organizations until they defined a clear set of standards for education and skills, Performance Engineering only applies to a subset of IT functions, unless of course your business *is* providing IT systems. Performance, however, does neatly fit into one area that has seen tremendous growth in the last few years; One that spans both Development and Operations. However, I won’t say what that organization is for fear of being called a bandwagon jumper.

will say, I spent a few years convincing my management (back when I was managing a team of performance engineers myself) that it would make sense to give us Production Monitoring as well. It would mean that whatever we were testing is what we would monitor for once applications were released, and that SLAs were vetted and measured by a single group who would strive to remain objective. It also meant many months of not quite knowing how all of that would work once they gave it to me, but in the end it was the right decision.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: