Business Development

Are bad Requirements our fault?

Over the past week or so, I've been reading Marcus Buckingham's First, Break All the Rules. I caught him at a conference last year and finally got around to picking up both of this books, so I've been looking forward to this.

Anyway, I'm approximately half way through it and while I was reading this morning, I was struck by something. Let me quote:

Conventional wisdom asserts that good is the opposite of bad, that if you want to understand excellence, you should investigate failure and then invert it.

He goes on to support this by pointing out that we tend to study things if we want to prevent them: student truancy, drug use, etc, etc. And I found this interesting when applied to some of my recent projects. Everyone tends to focus on "what went wrong and how do we fix it" instead of "what went right and how do we do more of it?"

As is common in the software world, we complain quite a bit about not having a specification. We talk about it to anyone who will listen... and I was actually doing it this morning. Maybe we need to change our perspective a bit. As John pointed out in his recent post, most of our customers and even we take things for granted in how they should work, how we perceive the world, and what we expect from our people and our tools. When we are working with something as intangible and complex as software, we need to focus on making things a bit more tangible and descriptive for our users. We have to make sure that they can understand some of the key things... not *how* we're doing something, but what the tradeoffs are.

I believe that we need to educate our customers on not only what is possible, but what is impossible given their constraints. Not only could this help clarify requirements, but it might completely eliminate silly requirements like "Build an auction system on par with Ebay".