I meant to write this last night, but I didn't get back to my room till late and just felt like crashing. I'm at the SD Best Practices conference in Boston this week, which is a new experience for me. It's one of a very few non-MS-oriented conferences I've attended, and I really wanted to come because best practices are a passion for me (and part of my job). Infragistics was kind enough to send me. I thought I'd share my experiences for anyone else considering going (and just for my own reference.. hehe) Anyways, enough of the intro...

Day 1 - Tuesday, 18 September 2007

First off, let me say I like the idea of starting on a Tuesday. It let me work for a good part of the day on Monday and still make it out here by train on Monday night. I've found in the past that attending sessions non-stop for a few days can really wear you out, so four days seems about right.

The conference is in the Hynes convention center, and I'm at the Westin, a stone's throw away. Also, it's right next to the Back Bay Station, so thus far the logistics aspect has worked out quite well for me. I'd personally much rather take a train over a plane anytime.

Responsibility-Driven Design

Tuesday was a day of "tutorials," which are half-day sessions. So in the morning, I attended Rebecca Wirfs-Brock's tour of responsibility-driven design (RDD?). I actually had her book at one point because it was mentioned in a good light by Dr. West in his Object Thinking, but somewhere along the line I seem to have lost it. Anyways, I was glad to get a chance to learn from the author directly and to interact.

From what I can ascertain, RDD has some good insight into how to do good object design. It seems to me that thinking in terms of responsibilities can help you properly break apart the domain into objects if you struggle with just thinking in terms of behavior. It's potentially easier than just thinking in terms of behaviors because while behaviors will certainly be responsibilities, objects can also have the responsibility to "know" certain things, so it is a broader way of thinking about objects that includes their data.

That said, it doesn't really negate the point of focusing on behaviors, particularly for folks with a data-oriented background because I do think that focusing on the behaviors is the right way to discover objects and assign them the appropriate responsibilities. I think the key difference is that with the object-thinking approach, you know that there will be data and that it is important to deal with, but you keep it in the right perspective--you don't let it become the focus of your object discovery.

Another beneficial thing I think Ms Wirfs-Brock has is the idea of using stereotypes as a way to discover objects in the domain. This is more helpful, I think, when dealing with objects that are more part of the software domain than those in the business domain because the stereotypes are very software-oriented (interfacers, information holders, etc.).

In terms of process, she advocates this idea of having everyone on a team write their thoughts down about the problem being faced in a few sentences, focusing on what seems like it'll be a challenge, what will be easy, what you've run into before, etc. Then have everyone bring those to the initial design meetings. I like the idea because it bypasses the introvert-extrovert problem you sometimes get in meetings and you can start out with a lot of ideas to really jump sta

rt the design. It's a good way to ensure you don't miss out on ideas due to personality issues.

The other thing I like in her process is writing down a purpose statement for objects as you discover them and thinking of them as candidates. This is part of the CRC card process (the first C is now "candidates"). The reason I like it is that it helps you to focus on the point of the object and sort of justify its existence, which can help weed out some bad ideas.

What I don't like about the process is the overall CRC card idea. While it surely is more lightweight than many ways to approach object design, you still end up with a bunch of paper that you then have to translate into code at some point. I much prefer to use a tool that will literally be creating the code as I design. I've found the VS class designer serves this purpose quite well. In fact, on the way up here, I spent some time doing up a sample class diagram using the object thinking approach to share as an example of domain modeling. I'll be sharing it soon, but I just mention it to say this is not just speculation. It was actually very lightweight and easy to discover objects and model the domain that way, and at the end I had literal code that I can then either fill out or hand off to other devs to work on who can then further refine it.

Domain-Driven Design

The second session I attended was one by Eric Evans on strategic domain-driven design. Eric wrote a book on the subject that's been well received by everyone I've encountered who spent time with it. I've seen a presentation on it, and I've read parts of Jimmy Nillson's Applying Domain-Driven Design and Patterns book. So I thought I was acquainted well enough with the ideas, but as I often find to be the case, if you rely on second-hand info, you'll inevitably get a version of the info that has been interpreted and is biased towards that person's point of view.

For instance, most of what I've seen on DDD is focused on what Eric calls "tactical" DDD, i.e., figuring out the objects in the domain and ensuring you stay on track with the domain using what he calls the "ubiquitous language." Eric presented parts of his ideas yesterday that he calls "strategic" because they are more geared towards strategic level thinking in how you approach building your software. Two key takeaways I saw were what he calls context mapping, which seems to be a really effective way to analyze existing software to find where the real problems lie, and distilling the domain, which is a way to really focus in on the core part of a system that you need to design.

In short (very abbreviated), he claims (and I agree) that no large system will be completely well designed, nor does it need to be. This isn't to say you're sloppy but it helps you to focus your energies where they need to be focused--on the core domain. Doing this actually can help business figure out where they should consider buying off-the-shelf solutions and/or outsourcing as well as where to focus their best folks. It's a pretty concrete way to answer the buy vs. build question.

Anyways, I'm definitely going to get his book to dig in deeper (it's already on the way). Please don't take my cliff's notes here as the end of your exploration of DDD. It definitely warrants further digging, and it is very complementary to a good OOD approach.

After all this, I was privileged enough to bump into Eric and have dinner, getting to pick his brain a bit about how all his thinking on DDD came together, his perspectives on software development, and how to encourage adoption of better design practices (among other things). Very interesting conversation, one that would have been good for a podcast. I won't share the details, but I'm sure folks will eventually see some influence this conversation had on me. Good stuff.

Software for Your Head

I almost forgot about Jim McCarthy's keynote. I've only seen Jim twice (once in person and once recorded). He's a very interesting and dynamic speaker, which makes up for some of the lack of coherence. I find the best speakers tend to come across a bit less coherent because they let speaking become an adventure that takes them where it will. But I do think there was definitely value in his message. I tend to agree that he's right in asserting that what we all do on a daily basis has a larger impact on humanity than we realize, and I can't argue with his experience in building teams that work. http://www.mccarthyshow.com/ is definitely worth a look.

Overall, Tuesday was a big success from an attendee perspective. So far so good!