For those of you that don’t know, I recently returned to the technical ranks as a Software Architect after a three-year stint in management. To make a long story short, I now love my job again. Perhaps I’ll write the long story in a future blog entry. On to the topic at hand. Today I led the first significant design discussion that I have led in quite a long time. A few minutes afterward, I was already reflecting on what had occurred and how. The very first thing that I noticed was my drastically different approach to the task. I felt that my facilitation skills were more mature and effective than I remember from previous similar engagements. I’m not sure if the time I spent in management (where I facilitated quite a few meetings, though much more business-focused ones) helped, but something certainly has.

I also noticed several things that I’ll call “pattern vs. antipattern” tugs of war. Quite often during the meeting I felt the group trying to move our discussion in one direction that I, for better or for worse, thought was ineffective. I would then redirect us on to what I felt was a better path. In true catalog form, here’s the list:

• Understand the Problem vs. Jump to the Solution – only a couple of minutes into our discussion solutions were being flung about like drunken darts. This situation almost always leads to suboptimal or faulty solutions. As a facilitator, try to ensure that the problem has been clearly stated. If at all possible, write it down on a whiteboard. Make sure everyone agrees that the problem as stated is the problem the group is there to solve. Sure enough, after performing this exercise, we all had a very different and clear understanding of the problem than that with which we walked in the door.
• Assume the Worst vs. Assume the Best – occasionally the exact details of a requirement are unclear, and not assuming something will totally derail the design discussion. You have a couple of choices. The first is to halt the discussion and get the details cleared up. This is clearly the best solution, as you’ll no longer have to assume anything. However, it can be the case that the person who can clear things up isn’t available. Or in some cases, the question you’ll be asking will require another meeting at another level of the organization. If you find yourself in that spot, and you can’t wait (we couldn’t!), then the best approach is to work from the worst possible case scenario. You’ll then be in the best position to handle whatever answer comes your way. However, our tendency is often to assume the best (“That will *never* happen!”). Fight that tendency. However, whatever you choose, follow up at your earliest opportunity.
• Basing Decisions on the Current Situation vs. Basing Decisions on History – many times the group wanted to veer off into safer territory. In some cases, a possible solution departed significantly from the current design. While this is a valid concern (we do want consistency of design across the system where possible), it is certainly not a trump card. Occasionally the situation at hand will merit a significant departure from the current design. Another way history can rear its ugly head is the assertion that we’ve always solved similar problems like ‘x,’ so we should do so with this problem as well. Again, note the word “similar.” All problems are somewhat different and have their own eccentricities. So, rather than working from history, I pushed us back to a clean slate with the statement “Let’s stop thinking about the past and start from scratch. We may very well come up with the same solution you guys are proposing, but I’d rather do so through our own objective analysis and not instinct.” Guess what. We came up with a different solution that we all felt better about.
• Shooting for the “Best” Solution vs. the “Easiest” Solution – now sometimes we can’t afford the best solution. I grant that. However, I’m trying to fight the tendency to immediately jump to the “easiest thing that could possibly work.” Often this pops up in the first P vs. AP – if we don’t clearly understand the problem, sometimes an easy solution jumps out that doesn’t deal with the underlying details we’ve yet to uncover. Also, sometimes the best solution is quite simple and elegant. It doesn’t necessarily have to be harder and more complex than the easiest solution. In fact, sometimes the “easiest” solution leads to the most accidental complexity in the long-run. So, shoot for the best solution you can come up with and only then, optimize for cost.
• Present Possible Solutions Objectively vs. My Solution is the Best! – one would hope that we all start here, but we don’t. We tend to like our own solutions to problems and want them to “win.” Our ego can get in the way of even hearing an alternate solution presented by another team member. I point you to my colleague Ted Neward’s post for more on “egoless programming.” So, as a facilitator, you’ve got to make sure that all solutions are presented objectively. I often had to say things like “OK, let’s assume before we ever get started that this is a good solution to the problem and not hack away at it until its fully presented, and we all understand it.” In the end, this insistence led us to choose a solution that none of us (myself included) originally thought we’d pick.
• Validating from Code vs. Validating from Memory – more often than not, questions about the existing design/code/behavior will come up. Rather than scratching your head and trying to remember what you wrote six months ago, pull up the code and find out. I can’t tell you the number of meetings I’ve attended where baseless assertions were made about existing code, only to require another meeting the next day to revisit the whole discussion once those assertions were proven wrong. Again, as a facilitator, I directed us to solve every problem for which all of the facts were available. We inserted placeholders in our solution where questions remained. Guess what we’re doing now? Well, I’m blogging about the meeting, but the rest of us are validating from code. Tomorrow will fill in the blanks!

I completed an interest survey for a potential Selenium-focused conference several weeks ago, and I’m excited to let you know that the “powers that be” have decided that the conference is going to happen! I have already submitted my “Executable Specifications: Automating Your Requirements Document with Geb and Spock” talk as a potential session. Whether it makes the conference program or not, I plan on attending the event. Here are the details:

Join members of the growing Selenium community for 3 jam-packed days of talks, workshops, lightning talks, and hack sessions. Hear speakers from around the world talk about the present and future of automated testing, share ideas with fellow Selenium developers, including Core Committers, and take part in shaping the future success of the Selenium project.

When: April 4-6, 2011
Where: Marines’ Memorial Club & Hotel, 609 Sutter St, San Francisco, CA 94102 USA
Register now to be a speaker or sponsor. More details: http://www.seleniumconf.com/

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 6,600 times in 2010. That’s about 16 full 747s.

In 2010, there were 15 new posts, growing the total archive of this blog to 115 posts. There were 24 pictures uploaded, taking up a total of 979kb. That’s about 2 pictures per month.

The busiest day of the year was June 4th with 139 views. The most popular post that day was Don’t build software that’s TOO smart!.

Where did they come from?

The top referring sites in 2010 were agile.dzone.com, java.dzone.com, twitter.com, Google Reader, and javablogs.com.

Some visitors came searching, mostly for matt stine, groovy http post, groovy post, groovy url post, and groovy url encode.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Don’t build software that’s TOO smart! June 2010
1 comment

Groovy: Post to a URL April 2009
4 comments

Resume March 2009

Deploying Grails with Groovy March 2009

LOTY Time Again: Scala or Clojure?!?! April 2009
17 comments

Today DZone released my first Refcard: “Selenium 2.0: Using the WebDriver API to Create Robust User Acceptance Tests.” I have been interested in writing a Refcard for a long time but have never pulled the trigger. For whatever reason, I decided to jump on the bandwagon last month. Writing this card was quite a challenge, as it’s difficult to boil down a big topic into only six pages while keeping it useful. Thus far the feedback from the community has been largely positive.

If you’re looking for your next automated testing tool for browser-based user acceptance tests, download the card and let me know what you think!

I’ve been really quiet on this blog lately. There have been multiple reasons for that. I’ve been extremely busy preparing for conferences this Fall including SpringOne/2GX and The Rich Web Experience. I’ve also stayed busy writing for DZone. I have my first DZone Refcard coming out soon, which is focused on Web Driver/Selenium 2. I’ve also been writing my regular articles for Agile Zone. Here’s a roundup:

• Modular Agile: Loosely coupled, highly cohesive ceremonies
• Think You’re “Doing Kanban?” Think Again.
• On Gaelyks and Golden Hammers
• Automation for the People (because Everybody Doing It Manually Hurts)
• Build Scripts? We Don’t Need No Stinkin’ Build Scripts!
• Automated Browser Testing: What’s in Your Toolkit?
• To Selenese or not to Test? That Seems to be the Question.
• Is the Apple JVM an “Extra Feature?”