How Shall We Define Design?

I love object-oriented design. It’s like open source software in general; perfect strangers come up with ideas that can save me time and money and then, out of the goodness of their hearts, go to a fair amount of trouble to pass these ideas on. I benefit from their efforts every day.

However, you don’t have to go far to find competent, thoughtful, well-intentioned folks who curse and spit when they say ‘design’. To these folks OOD is anathema; they see it as useless excess that must be avoided at all costs.

Two things are odd about this situation. First, while I’m certainly no genius, neither am I a complete idiot. As a woman of a certain age I’ve been writing code for an alarmingly long time. I have tons of experience getting applications out the door and my experience is that OOD lowers costs, increases output and keeps code fun.

Second, when I listen to the anti-design folks explain their points-of-view, I agree with about 99.9% of what they have to say.

How can I simultaneously love design and agree with almost 100% of the statements made by folks who profess to hate it? Well now, that has become obvious, hasn’t it … we must be using different definitions for the word.

I define the design of an application as the current arrangement of its code, and the act of design as using ones knowledge of the consequences of various code arrangement techniques to solve the current problem in a way that accommodates the next (as yet undefined) change. The anti-design folks (if I may speak for them) use design to mean making guesses about unknown requirements and writing speculative code in an attempt to preemptively meet them. By my definition there’s no such thing as over-design, by theirs the terms design and over-design are synonyms.

My experience is that participants in pro/anti OOD arguments agree far more than they disagree, and when they can’t agree that they do agree it’s because they’re stuck to their own definitions of the word. These disputes are not about core beliefs, they merely reflect a communication gap.

I was thinking about this issue while listening to the Ruby Rogues episode with David Heinemeier Hansson, and serendipitously, in that same episode Chuck mentioned that he’d been experimenting with mind maps using MindMeister.

I sat down to organize my thoughts and ended up with this mind map:

How cool is that? I (for one :–) ) now feel a pleasing sense of clarity. If your thoughts about OOD map a different way, let’s hear about it … or better yet, make a map of your own and share it.

In the meantime, if you’ve written applications that have become painful to maintain, my definition of design offers a way out. The purpose of OOD is to reduce the cost of change and the principles of OOD let you create applications that simultaneously do the simplest possible thing today and stay out of your way tomorrow. The folks who don’t feel the need for design are clearly not having trouble with their apps, but if you’re have trouble with yours, OOD can help.

Posted on July 5, 2012 .