Working--share your experience

One of my all time favorite books is Studs Terkel’s Working. In it, he captured people talking about what they do and how they feel about it. People tell amazing stories about hard work. The book is about, "ulcers as well as accidents, about shouting matches as well as fistfights, about nervous breakdowns as well as kicking the dog around." I hope you don’t find software development so grim (I don’t ). But maybe you have an intriguing story to tell.

OOPSLA is soliciting Practitioner Reports. The submission deadline is just a short time away--March 19th. If you submit a report and it is accepted, Ralph Johnson or one on his committee will help you tell your story. There are many more interesting stories to be told and if you have one, please consider telling it at OOPSLA. Last year there was a really great story about how software objects finally made it to space in a JPL satellite through the persistence of a guy who really, really believed in the benefits of oo programming. A grad student at Portland State presented his experience exploring Traits--when he was an undergrad. I remember another report where a developer recounted his use of refactoring tools to write transformation rules to transmogrify a massive Smalltalk legacy application’s database access layer. And I recall another telling how a framework for scientific applications evolved. There are always interesting stories to tell—and OOPSLA is a place where you can tell them, whether they be about your latest adventures with web services, domain-driven design, aspects, agile or open source development, or the challenges of developing applications in distributed teams.

Agile Open Northwest was for real

Last week for two days at the Kennedy School in Portland 100 people discussed agile software development at the Agile Open Northwest conference. Open spaces don’t have a set agenda; instead people propose topics around which they have a passion. That’s the beauty of an open space—the agenda is formed on the spot. We’re talking, not just listening. Conversations and sharing are key. I enjoyed Dale Emery’s session where he led us in reading Dr. Seuss’ Green Eggs and Ham and we discussed how to overcome resistence. I learned about the role of games and simulations in training and had fun playing a couple. Thanks Elisabeth! And I felt the pain in a session where we discussed how to sort out differences of opinion on a dev team.

Open spaces aren’t just someone talking and everyone else listening (although some sessions were more one-sided exchanges of information than others). The place was abuzz with conversation. As one of the hosts for the event, I was nervous about whether enough people would show up and whether they’d have enough to talk about for two days. I shouldn’t have worried. People were engaged, excited, rejuvenated, and happy but tired at the end.

Is there a secret sauce that makes an open space work? Probably no one factor is “the secret”, but there seem to be several key ingredients. First, the open space needs to be “open”. People need to be encouraged and empowered to take responsibility to make the conference what they want it to be. There is a structure into which open conversations can be fitted. At the beginning, attendees propose topics and session times which are posted on a big schedule board. People are encouraged to get what they want out of any session. It’s perfectly OK to vote with your feet and leave a session to attend another, or to flit from one to another. It’s OK to sit out and just hang out for a while (I got tired and needed a break on that second afternoon). And throughout the conference new sessions were proposed and times reshuffled.

A good facilitator is invaluable in setting the tone and expectations. Diana Larson, another conference co-host, convened the open space and ran the daily news and closing. She was fabulous. It helps if the open space has a theme or burning question to explore. For us, it was “Agile for real.” Originally, we thought it should be posed as a question. But we left it as a statement that could be interpreted as a challenge—what does it take for agile practices to really work. Get real.

A comfortable location helps. The Kennedy School had a funky charm that is hard to match in a convention center or hotel. Coffee, tea, and bottled water were available throughout the day. Breakfast, lunch and dinner were included—so people didn’t have to break their stride to find nourishment. Finally (and this was really nice), there was wireless and computers were provided so people could record their session notes on the conference wiki or check on email.

While the face-to-face discussions are over, things that came out of the open space continue. The Portland XP group is being revived; an open space is being planned for the bay area; the next generation of testing frameworks is kicking off serious discussions... It may be over, but stay tuned for Agile Open Northwest 2008. This was too good to be a one time event.

Martin Fowler is no Kent Beck

I know the difference between those two....When authors make mistakes, readers notice. In my latest IEEE Software Design Column, Driven...to Discovering Your Design Values, I quoted Martin Fowler as claiming that test-driven development,

“gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.”

Kent quoted Martin in his book Test Driven Development by Example.
It gets a little tricky when you cite someone quoting someone else. Originally, I had the reference to the book in line with the quote attributed to Martin (but my citation only listed the book title, not the author). My editor moved that citation to the back of my article and undstandably filled in Martin as the author. Easy mistake to make and I didn't double check the references when it was refactored. I assumed my editor would fill in the author appropriately and double check citation.

My fault. You heard it from me first. When anything is refactored, whether it is code or citations or comments, you need to check twice. Since I don't have an xUnit tool to write tests for citations and quotations, this has to be by visual inspection. I'll know better next time. Thanks Mirko and Shinobu for caring enough to email me about this mistake.