There’s nothing like getting off of a plane, taking a shower, then showing up almost-late to jam with a bunch of software engineering professionals. There’s nothing like it, and career-wise, it was one of the best weeks I’ve had.

I was in Miami two weekends ago for a friend’s wedding. After missing the vows — we got lost! — paintball, and an extremely great weekend, I flew back Monday morning and headed straight to the pre-WOPR event. WOPR, for those that don’t know, is the Workshop on Performance and Reliability, and “pre-WOPR” is a similar workshop held a few days beforehand.

Like all workshops previously, I had a bit of nervousness going in. For this one specifically, I felt I didn’t have much experience related to performance testing, and I felt… well, performance anxiety (pun intended) because I’d have to to participate with folks each having 10 - 30 years experience in the field. To make matters worse — as nervousness is concerned — for WOPR, I was asked to give my views on each experience report, in front of the group, after group discussion finished, in a spotlight that became known as “Tim-bits”. For a newbie out of college, this was some pressure.

Though I had nervousness going in, I enjoyed both workshops immensely. I wrote my Tim-bits down — as “sound bytes” that best describe what I learned — and am providing them for WOPR, pre-WOPR, and the world!

I’ve attributed each bit to the experience report that led to it; however, I would like to stress that many of these bits were the direct result of group discussion afterward. Attribution not only goes to the presenters, but to everyone who attended the workshop.

1. Exercise-centric courses that are meaningful to the audience will be more likely to produce better performance testers in a practitioner-based performance testing course. (Ross Collard, independent consultant)
2. Tools don’t solve problems, they help people solve problems. Like a hammer helps in building a roof, our tools help in doing performance testing. No one tool will do our work for us. (Goranka Bjedov, Google)
3. Performance testing’s monitoring tools are very much like astronomy’s telescopes. Although our tools do more and more things everyday, the best monitoring tools will be those that provide more — and more accurate — information. (Scott Barber, PerfTestPlus, inc.)
4. The same problems in consultant-taught performance testing courses exist in academic professor-taught courses: Fuzzy prerequisites; diverse student backgrounds; variable student interest; turbulent teaching environments. They’re all there in both contexts, and the problems generalize. (Gustavo Vazquez, Uruguay Center for Software Testing**)
5. a) The knowledge of a good performance tester intersects all facets of software engineering. When teaching them — for one course, at least — you must give them a slice of programming, a slice of process, a slice of statistics, and a slice of practical testing environments. Doing so successfully is difficult. b) Bureaucracy, and conflict of interest by those in power (management) can screw up a very effective testing course. (Dawn Haynes, PerfTestPlus, inc.)
6. Graphs, graphs and more graphs! They are — as far as we know — the quickest and most powerful way to give decision makers the information they need to make release decisions. Prepping the decision makers beforehand at the start of the testing process will set expectations and create a healthy reliance on the testing group. (Jude McQuaid, Intuit)
7. Relate performance testing to beer.*** (Andre Bondi, Seimens)
8. Apprenticeship in performance testing has benefits in some contexts, and is more beneficial when testers are newer (avoid the word “junior” ). Also — like a Sith Lord — it’s too hard to manage too many apprentices. (Roland Stens, independent consultant).

** Gustavo: Let me know if that’s the correct translation.

*** His slides are available — and I’m working on getting them — that explain the analogy much better. The group roared with excitement when he showed them, and some said it was “the best performance testing analogy seen yet.”

Though there’s much more detail lurking behind each bit above, the biggest thing that struck me was non-technical — rather, it was how comfortable I felt throughout these two workshops.  I can’t quite pinpoint the exact nature of this comfort, or what made these workshops different than the many others I’ve been to; however, in general, I finally feel like I’m “part of the group.” I probably always was — heck, I’ve been dubbed a “wolf” for a long time now — but I think the realization is finally setting in. Big thanks to all!

Speaking of thanks, I want to thank Rob Sabourin for being content owner; Ross Collard and Scott Barber for co-organizing; Julian Harty and Goranka Bjedov for hosting; Paul Holland and Nick Wolf for facilitating; and all the participants who made WOPR and pre-WOPR great events to attend. I learned a lot — more than what my Tim-bits might show — and I appreciate all the great insights that came from this experience. Thank you!