We’re getting some Google attention at the geo-side of our organization. Today, TOPP’s work on GeoWebCache made Google’s open-source blog, mentioning GeoWebCache’s lead developer Arne Kepp.

Good work guys!

Update: Alright, full disclosure. I just realized the post was written by Chris Holmes, TOPP’s “geospatial CEO.” It’s still pretty cool, but a little less so.

I just gave a presentation at work about my experience at WOPR. From what I can tell, it went great, and was a good introduction for the organization.

Here are my slides.

They were crafted specifically for The Open Planning Project, though they may be useful elsewhere.

A big thanks goes to everyone at WOPR, and a thank you goes to David Winslow at The Open Planning Project for setting up this talk!

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!

The Open Planning Project just released a small community website for those in the greater NYC area: http://www.blockpartynyc.org

From here:

Block Party NYC is a new program by the New York City Streets Renaissance Campaign helping neighborhoods around NYC come together and enjoy their street, free from the usual hazards and distractions of automobiles. This summer, we’re providing mini-grants to over 30 block parties throughout the 5 boroughs, [as well as] the services of a professional urban planner to combat community problems like traffic, speeding, noise and air pollution.

Interested in meeting your neighbors? Getting outside? Having some good ol’ fashioned family fun? Well here’s your chance.

I’ve tried to write this post many times. I’ve tried taking different strategies, from telling a story-based account that led me to an idea, to being blunt and direct about what I was trying to say. I even tried using big words that act as “intelligence flags” for those who don’t understand the message. Though I made three tries, I was satisfied with neither.

Instead of trying to talk around a topic that doesn’t seem to have a whole lot of discussion — nothing that I can divine, anyway — I’m instead going to say it very cheaply.

Given these premises: …

1. Bug reporting systems are communication tools that aide people in talking about software defects, problems, bugs, etc.
2. Bug reporting systems intentionally or unintentionally become huge silos of information that don’t play nice with other software.
3. Bug reporting systems encourage communication that is formal, dry, and sometimes (most of the time?) uninteresting.
4. Bug reporting systems are not people focused.

… And, given this observation: …

1. Bug reports and blog posts are essentially the same technology. They are, at their core, a block of text followed by inline discussion.

… I’ve come to this conclusion:

1. Bug reporting systems are rather old technology, and their creators can learn a lot from the blogging movement.

What if bug reporting systems had trackbacks, for instance? Or a meaningful RSS feed?* Or maybe, “What’s new?” “What’s interesting?” or “What’s the hottest bug that we know of right now?” What if a bug report displayed who was talking about it (e.g., who linked to it) or performed the mundane task of figuring out which bug reports were related (again, who’s linking to it)?. Wouldn’t that make things easier? If there was a better interface — rather than the top of the bucket — that management could peer into, wouldn’t that solidify the role of the testing organization and help management keep track of their software’s status day-to-day?

Isn’t that bug advocacy?

This all stemmed from our use of bug reporting systems at The Open Planning Project. In short: One Big Bug Reporting System is unmanageable given many users and many avenues of input. Eventually, the silo will become too big. Multiple bug reporting systems are unmanageable given software systems that are tightly integrated. Eventually, a single bug will affect each system, and multiple people — whose hands are somewhere within each bug reporting system — will have to respond to it.

I almost hate to say it, but online bug reporting systems are the oldest Web 2.0 applications I know. So why have they fallen so far behind?

* Our system, thankfully, has an RSS feed, though my impression is most bug reporting systems are behind the times.

PS: I could be convinced that all I’m really suggesting is that Y generation testers will start advocating bugs to management through current Web 2.0 technologies, such as blogs. However, I wouldn’t be disappointed if some bug reporting systems learned from the blogging movement, evolved a bit, and became more open to information sharing across a large, interested audience.

My current open-source favorite is Trac. No guarantees, but there may be a new plugin on the horizon.

I can’t say it’s been a horribly eventful week; that, coupled with the loss of over half of week three, I’ve lost a bit of motivation for being very detailed. Instead, I’m going to write this one a little differently.

Some highlights of last week:

• I was sick — not sure why — for the third time since I’ve been to NY. People told me this is a dirty place; I’m inclined to agree with them.
• Rebecca Sanders, a graduate assistant of Rob Sabourin, started a task analysis of how we do our testing with a series of phone interviews. It’s really exciting actually, and I can’t wait to see how we stack up to Rob’s other case studies.
• Using one of my managers terms, it seems as though I’m “divining test ideas,” rather than getting them directly from stakeholders (or, divining them more than getting them directly, as I think some divining is requisite to the position…). Although I’ve been told I’ve been doing a fairly good job at it, an increase in communication will only make things easier on everyone.
• I’ve started a formal way of reporting the most important findings of the testing group. See here.
• We’re falling into a good groove, I think. I’ve lost my second tester again due to development concerns, though I feel my other tester is doing an amazing job with there only being one of her. She’s really hit some vague charters with research and attention to detail, and she’s found out some important information about the system. I have no doubt this will continue in light of other vague charters I decide to throw at her.
• There’s been talk that a team of temps may be added onto the testing group that could multiply the size of the group by eight (that means eight people total). I haven’t had the real conversation with stakeholders yet, so my numbers may be off, but my impression is promising.
• I’ve been approved to be a TOPP ambassador to a few conferences and peer workshops, including CAST 2008. Thank you, TOPP.
• Speaking of CAST, I got an email that said papers are coming in. I’m on the paper review committee, and am excited to review my first conference paper, ever.

Even though being sick colored my feelings (and productivity) during the week, in hindsight, I think it was a great week with some great variety.

This one’s a long one folks. Click the “Read More” link below to view the full play-by-play.

(more…)

Alright folks, here’s the next installment of the play-by-play. This week was a shorter one due to observing the American holiday, and it was also shorter due to the huge wave of things happening this week (it was hard remember everything). Enjoy, and as always, I appreciate your comments.

Click on the “Read more” link below to view the full play-by-play.

(more…)

Alright. So it’s been a week since I was given the chance to be “test manager” for our small project. I spent some time cataloging my reactions, and figured it would be interesting to others. I’ve written them as a play-by-play, to best describe my reactions as I had them. This is a long blog post — almost too long — but I think the detail is worth it, both for me and for anyone who’s interested.

Click “Read More” below to view the full play-by-play.

(more…)

If you haven’t seen my previous post, I’ve been given the chance to lead a testing group for the next few weeks. For this new role, I was told to document my process. This is what I came up with.

Although I think I have most stakeholders already onboard, I wanted to create a proposal that outlined some of my ideas about testing, as well as how we’ll do session-based test management. Even though I could have just “documented my process,” — they’re giving me a lot of free reign here, which I love — it’s a proposal because… well, it’s likely going to change, and I’m not the only one with input.

I have this fear that it’s too general — which, it likely is — but I think the specifics will come as we flesh out what works best for us. George Box comes to mind: “All models are wrong, some models are useful.”