I’ll Know It When I See It

While looking through the stories my friend Robbie had shared via Google reader, Bring me a different rock caught my eye.

Robbie and I worked together for a couple of years at a big corporation that was sometimes often afflicted by the “wrong rock” type of thinking.

This is a game where you attempt to guess the requirements of a manager who cannot or will not communicate his or her goals, and the best attempts to do so resemble a series of frustrating discussions where you are told that your “rock” (product, schedule, process, proposal) is not correct and you should present a new “rock” in a short time frame.  The problem is, the person who is rejecting your “rock” is unable or unwilling to describe what an appropriate rock looks like, feels like, tastes like.

It’s a terrible situation for everyone involved. No one in the chain ever gets to feel good about the work they’re doing because they never feel certain that they are working on the “right rock”.

That premise reminded me of a great post by Joel Spolsky from October, 2000 about functional specifications.

The moral of the story is that when you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs. What’s worse, a programmer who’s just spend 2 weeks writing some code is going to be quite attached to that code, no matter how wrong it is.

I have tried to do web design for two clients who fell into this bucket. “No, I don’t like that, but, I’ll know it when I see it”. I’ve since learned my lesson. I can’t imagine ever working with a “I’ll know it when I see it” client again, they drain you and in the end, they never seem to “see it”.

The ideal client is one who is an expert at his business, and allows you to be the expert at yours.