The problem we were given came from Don Roberts, whose wife is a veterinarian. We were tasked with coming up with a design that would allow a veterinary hospital to keep track of its patients and their owners and bill them appropriately. Sounds simple, until you realize that you can have race horses owned by multiple people, each with a different percentage stake… and, of course, many more complications. The group quickly divided into two. One group wanted to try a pure Test-Driven Development (TDD) approach, while others wanted to go for a Prototype. I was in the prototype camp.

The interesting thing about a prototype, is that while the actual development is quick (in theory), there’s still a good deal of work that needs to go into the design before you can start programming. A prototype is usually a set of minimal functional requirements that sort of work. In that sense, it’s not too different from “hacking”. (Yes, we got into a discussion about “prototyping vs. hacking” that derailed us for a few minutes). What happened was we ended up focusing all of our energy (and time) on coming up with a solid, complete Object-Oriented design for our solution. The result of our design was little more than a class diagram on paper, but we were able to work through every use case thrown at us.

The TDD team found that they, too, needed some initial design work to be done before they could start writing the test cases that would yield code. I have trouble wrapping my head around a pure TDD approach. I understand how TDD can work if your requirements are well-defined and you already have a design that you can code tests against. The idea is that you write test cases for the design before you write the actual code. They will fail initially, and your goal as a programmer is to make them pass. In that sense, it is indeed Test-Driven Development. I’m not sure the concept can be extended to Test-Driven Design. The TDD team had little more than one test case, but they had actual code for one of the use cases, which is more than what we had.

The ensuing discussion was extremely stimulating. It’s amazing what happens when you get a bunch of really smart software geeks in a room together.

The key realization that I took away from this experience was that software design is a social activity. Even though we hadn’t met each other previously, our team had to work together. We had to help each other out and make sure we were all on the same page. We had to communicate. It was amazing that we didn’t have a lot of trouble doing it, though. We mostly seemed to agree and moved along at very reasonable pace. Maybe it’s just because we’ve all trained our brains on OOP for so long.

One question in the discussion stuck in my head the most, and I’m still thinking about it. Don asked “What is the language of design?”. Since software is collaborative and social, it follows that like any human language, we must take some concept from our minds and communicate it to someone else. If any non-programmer happened to be walking by our table, we would have sounded like the Children of Tamar. Our speech consisted of terms taken from object-oriented programming (”object”, “class”, “instance”), UML (”association”, “composition”, “aggregation”), and Design Patterns (”state pattern”, “template method”, “strategy”). And that was just the spoken part.

Software Design has a grammar. There is a way of communicating design that involves a vocabulary as well as a set of rules describing how to put sentences together. And I don’t mean English. Design is more like a mash-up that derives itself from UML and Design Patterns and English. Whatever it is, we need to ensure that those designs we have floating around in our heads can remain intact after we’ve thrown them into the ether. I think this is where a formal design language specification like UML falls short. It’s so restrictive that most UML tools require you to input far too much information before they’ll display a simple diagram. Thus defeating the purpose. UML diagrams need to be free-flowing and erasable. The language doesn’t have to be perfect, it has to be understood. More importantly, it doesn’t have to be understood by a computer — that’s what programmers are for. But programmers are people. So, design has to be understood by people. People are capable of parsing an imperfect sentence that might not be “grammatical” according to a formal specification, but can still be understood by those natural language processing mechanisms we call brains. It all comes back to software design being a social activity.