Part 2: The Neglected Basics: does the magic list exist?

In Part 1 of this series, I was complaining that we rarely draw the line between the development and performance teams, divvying up the responsibilities for making the system perform.  Who's going to do which parts?  When the developers do nothing, we end up something real similar to the spectacular failure of the healthcare.gov launch.  When developers do too much, we risk premature optimization.

But before we can assign tasks to groups, we need to decide on the list of tasks.  Does such a list exist?  Let me tell you a quick story about me getting grilled by a 'new sheriff in town' performance manager.

I switched from java development to performance tuning in 2006.  Once of my first performance managers had come from the functional QA side of the house and he immediately took me off guard.  "How can we train performance engineers if you all don't even have a plan to begin with?", he asked me.   I was a little stunned.  blink.  blink.  I was just asking for a training budget and he wanted to question my credentials.  He was skeptical that performance people had any clue what they were doing, and was eager to put me on the spot, and I had just enough doubt to question myself.  Do we really have a repeatable game plan for delivering well performing applications into production?

Several years later after a lot more performance work, I can report that that notion is silly,  that we don't know what kills performance.  The performance teams I've led over the last 8 years have become board stiff (bored but overworked, actually -- not a good combination).  We bolt the monitoring tools onto the applications and look under the covers.  What we see is mostly the same boring, preventable problems on the list, year after year (here are 3 big hitters on my list).  Perhaps your list is completely different than our list.

I'm good if your list and my list are different -- I just think all projects need to establish _some_ list of performance anti-patterns to be avoided, and someone needs to assign  throats-to-choke to each item on the list.   Do your development teams do this? Are performance considerations even included in design?

Assembling this magic list is not an easy task.  Don't have time right now, but I need to finish my blog entry about which group is best suited for various tasks.  Part 3.

Also unfinished is an entry about how I kinda crashed and burned with my first two attempts to get development teams to work with a list.  Hopefully you can learn from these mis-steps which will be Part 4.