~pperalta

Today is a brisk fall day here in Boston where the SD East Best Practices conference is getting started. The first day consists of half day tutorials, one before lunch and one after.

The morning tutorial that I attended was presented by Luke Hohmann of Enthiosys. The topic was “Innovation Games: Creating Breakthrough Products Through Collaborative Play.” The focus of this talk was strategies that can be used to solicit customer input and how to process this data to turn it into innovative products. The techniques consist of games that can be played with small groups of customers in order to understand their wants, needs, and priorities. They have an entire catalogue of games that can be used for various purposes and audiences. During this presentation he went through three of them: Speedboat, Buy A Feature, and Spider Web. The game that I found the most interesting was Buy A Feature. Each customer is given a certain amount of play money and a list of features along with their cost. The customers then get together and decide which features they would like to “buy.” Sometimes features are expensive and a single customer does not have enough to purchase the feature, thus they must collaborate and pool their money together to get what they want. I like this game because it demonstrates the constraints (especially time constraints) that developers have, but it puts control of what goes into the product in the customer’s hands.

After lunch it was “Principles of Object Oriented Component Design” with Robert C. Martin, AKA Uncle Bob. The theme was software complexity and how OO design can make software simpler to write and maintain. OO systems that have modules that have cyclical highly coupled dependencies are very difficult to modify. Changes made to one part of the system can affect other parts of the system that are not related. Thus, Robert describes how to build systems that are loosely coupled by actively managing dependencies across modules. In practice this is harder than it sounds because all it takes is one wrong import statement (or the wrong #include) to create a cyclical dependency. (For the purpose of this talk, the definition of a component is an isolated binary that can be deployed independently, such as a jar file or a dll.) With Java, JDepend can be used to avoid this problem. Dependencies should always flow in one direction across modules; in other words module A must never depend on module B. Sometimes this cannot be avoided, so a few techniques can be used to avoid a bad dependency:

• Copy and paste the code from module A to B. Hint, this is not the best option.
• Refactor the functionality to a module C, and have both A and B depend on it.
• Express the functionality that B needs from A as an interface. Define that interface in module B, but have the implementation injected from module A.

It would be nearly impossible to determine up front exactly which modules should exist and what their dependencies should be. For this reason, he advocates a design that evolves over time, which is the Agile approach. As I pointed out to him, skills in test driven development and refactoring are absolutely crucial in order to develop in this fashion. Without the ability (not to mention the tools that IDEs provide) to refactor, developers will be reluctant to shift code around that already works. TDD is the tool that gives developers the confidence to restructure and move code around because that is how they know that nothing was broken in the process. Although he did mention using interfaces quite a bit in the talk, I think that interfaces play a huge role in loosely coupled classes and modules. I think this point could have been emphasized more, but then again maybe it would not have been necessary for the target audience.

Tomorrow morning is his talk on Clean Code:

This class is about code. We will put code on the screen and we will read it and critique it. And then, one tiny step at a time, we will clean it. In this class, you will participate in the step-by-step improvement of a module. You will see the techniques of the Prime Directive (Never Be Blocked) and Agile Design principles brought into play. You will witness the decision-making process that agile developers employ to write code that is expressive, flexible and clean.

Conferences don’t usually go this deeply into coding, so I’m looking forward to this talk!

Here are more pictures at the conference.