I just got home from a 3-in-a-row conference marathon. First I went to the Patterns of Programming Language Conference or PLoP in Nashville, where our paper Dynamic Factory, co-authored with Leon Welickiand Joe Yoder, was shepherded in a writers’ workshop. This was my first PLoP where I actually had fun. Our writers workshop group was a sharp group and gave everyone excellent feedback. The first time I had a paper workshopped at PLoP a couple of years ago I was disappointed about the quality of the feedback. Speaking with more seasoned patterns conference attendees, I learned that workshopping is hard work--and not always does it work out well. It takes a combination of a skilled workshop leader, workshop attendees who’ve critically read their papers, and a good mix of insight and discussion. Sometimes, even with the best intentions a workshop doesn’t deliver good feedback to every paper. When everything comes together the results are amazing.

Then it was on to OOPSLA where 750 geeky souls met to discuss programming languages, design, practice, and what the next software trends might be. At OOPSLA I presented a keynote, What Drives Design? that I’d spent the last five weeks working on. I talked about the main ideas behind Responsibility-Driven Design (the first, “driven” method) and then compared and contrasted several different design methods. For the record, I characterized TDD as “design between the keystrokes” and Feature Driven Development as “Design first, program next.” Truth be told there is a lot of design that happens when people practice TDD. But refactoring isn’t the same as initial design ideating. It still begs the question, when do you do an initial design (if ever)? Is it always at the keyboard? Scott Amber, with Agile Model Driven Development interjects a “model when you need to” front end to TDD practices. Not specifying what you should model, but giving people the framework to plug in non-programming design efforts when they think they need them.

Last week I was at SD Best Practices in Boston--the consummate conference for those seeking technical trends and practical advice. I presented my tutorial,The Art of Telling Your Design Story, and a talk on Giving and Taking Design Criticism. At the conference I enjoyed hearing Neal Ford take a swipe at the inefficiencies/unnecessary clutter of implementing design patterns in traditional (read non-dynamic) languages. Neal is a compelling speaker. At the end of his talk I was convinced that Ruby doesn’t have anything over Smalltalk. Neal confirmed my thoughts about Smalltalk. Still, I plan on taking a deep dive into Ruby this winter.

I’m somewhat concerned when DSL-makers tack on behaviors to any class of thing in order to have a fluent language. While that may work in the short run, I’m betting meta-programming tricks and behavior hacks to basic classes won’t scale. Call me a traditionalist, but I remember the clutter of extra behavior tacked on to Objects, Integers and Strings causing real problems in Smalltalk. It wasn’t considered good practice then...and I’m not sure I’d make the same “fluent language” tradeoffs Neal wood. Still, his talk got me thinking.

I also enjoyed hearing Rick Brenner’s Organizational Politics for Those Who Hate Politics. While I don’t have office politics to contend with in my own business, I do encounter lots in my clients. SD Best Practices is a conference where you can blend geek topics with management or professional development topics and come away feeling well-rounded.