Wednesday, July 7, 2010

Over design and the “but” exercise

Do you suffer from “over-design”? Do you even know if you over design? Is there any way you might be able to self assess? (Are you asking, "What is this "over-design" of which you speak?")

Here’s an exercise you can try on yourself (you can also try this with a team, but I’ll have more to say about that below).

The exercise seems simple. Count the number of times you say “but” in a day. Simply track it. Don’t do anything with the number, just count it. That’s it. You can get a bit more sophisticated and add other words and expression such as:
  • However
  • That won’t work
  • ... because

You might want to consider working up to that.

Warning, you might be thinking it as well. Count those if you can. Or, maybe work up to those as well.

Ultimately, what you are trying to do is simply observe the number of times throughout the day you reject an idea. That’s often what you do when you use the word but.

In an of itself, rejecting an idea is not a problem. Even a pattern of rejection is not a pattern. Observations like this are data. You might try to find patterns or correlations such as:
  • I tend to reject Andy more than I reject Mary
  • I seem to reject ideas in the morning or during lunch
  • Initially I reject ideas from my wife that require me to do work. I tend to come around (this is one of my patterns).

Once you discover those patterns, you might ask yourself if they fit for you. If they do, great. Maybe you got a little personal understanding. You probably became more keenly aware of how often you tend to reject ideas.

You can take this one step further to find times when you might be rejection and idea and are not even aware of doing it. Try the exercise again. This time, rather than counting the number of times, instead make the observation that you are saying “but” (or some other such expression). As soon as you do, and this is key, try to figure out where in your body you hold that feeling. It might be in your stance, hands on your waist. It could be in your celiac plexus, shoulders or your neck. If you are not used to making these kinds of observations, it will probably take many tries before you notice. You've probably become so used to manifesting a physical response to a given situation that it’s like fish in water.

As you become able to make these observations, then next thing to look for is patterns. Maybe:
  • When I talk to women and reject their ideas, I stand in a particular way
  • I tend to get hungry when I have to say no

As with the previous exercise, it’s data. Does the habit fit? If so, great. If not, then maybe try to find a way to break the habit. What you are doing is turing unconscious decisions or habituated behaviors, into conscious ones. You are giving yourself more choice. Really, you’re taking control of yourself from patterns you’ve picked up over the years.

There are several ways to do so. You might simply:
  • Smile in that situation
  • Breath (through the nose into the pit of the stomach)
  • Put a micro-bend in your knees
  • Tapping (the NLP variety, though if you have the shoes...)

The interesting thing is that making these kinds of observations will mostly likely result in some kind of change. Awareness tends to lead to change. If a particular behavior fits, then the observation will not likely change a given behavior. However, it might still make you aware and give you other options.

What about trying this in teams?

Danger, danger.

It’s certainly OK to try this with a group. One thing I’d be concerned about is applying a metric to the result of the count. For example:
Brett is the most negative, I counted how often he said “but” and it was the highest

This is a personal exercise. It’s easy for it to turn into a competition. While you might ask someone to help you notice something you are doing, it’s easy to turn a simple exercise like this into an ongoing battle.

How does this have anything to do with over design?

Have you ever noticed that moving from the design of a solution to the design of a framework is made with one “...but what about this...” at a time?

I’m certainly guilty of this.

On the one hand, implementing with too little context can lead to a myopic design. On the other hand, considering too much context often leads to over generalization (framework-itis). There’s certainly a balance somewhere in there.

Over design is a problem when you’ve designed for A but you really needed a design for B. Over design typically is more like, "I’ve introduced flexibility for A, B, C, D, E, F, G but you needed a subset of F".

How can this “but” exercise help?

When you are working through requirements on your way to design, simply track how often you ask the questions in a form such as “...yes, but what about...”. Every time you do, a kitten dies. Are you missing the forrest due to all of the trees? I've noticed this in myself and I think it's a pretty common characteristic in developers.

Extreme Test Driven Development is another way you can avoid over-design at the possible expense of myopic design. As with most things, there are many good paths somewhere in the middle.

In any case, if you think you might be a culprit of over design, or maybe even being a bit of a Negative Nancy, maybe this exercise could help you determine patterns driving your behavior. With that information, you might consider trying on different patterns to see if they fit better.

No comments:

Post a Comment