SyntaxHighlighter

Thursday, August 4, 2016

Prototype Rocks Are Better

A common analogy with my bosses is "Bring me a rock." This fictional conversation between an "idea person" and "engineer" would go something like:

Idea Person: "Bring me a rock."
Engineer: "Here is a rock."
IP: "It is not dark enough."
E: "Here is another rock."
IP: "Why is it so jagged?"
E: "You want a darker, smooth-ish rock?"
IP: "Yes, obviously."
E: "Here is a rock."
IP: "...it's too small."

We are not geologists, and this conversation is not really about rocks.

Ideas are not bad. Quite the opposite, they are necessary! People who come up with ideas are vital from an entire organization down to a small development team. New products or features were not written down long ago and rehashed; they were new ideas at some point and through many steps, and sometimes many iterations, became reality!

Ideas are hard to pin down, and sometimes they are fluid. When a person has a great idea, there are steps involved to make that idea real. Many steps. Rambling off a few sentences of the idea and thinking it will be done to any vague expectation of success is hard to achieve. Especially to an engineer who needs (lots of) details.

And yet, this happens all the time. Which is normal in a lot of cases, and idea people and engineers work together to make it happen. It's called "design."

This  situation becomes a problem when the idea person and the engineer are not working together. Suddenly the idea person wonders why their simple idea is not done yet, and the engineer is frustrated at wasting time on undefined "requirements." Two or three iterations of "Bring me a rock" can wear someone out! Compound this with an idea person that changes their idea before the engineer shows them anything, already invalidating some of that engineer's work! Aaaaarrrgh!

That why you need a prototype.

Having a prototype type is the place to really start a conversion with those idea-person-types. It is tangible. It is something to talk to and point at. The dev team needs to get that prototype ready as fast as they are able (keeping in mind their process and maintainability goals), and the "idea people" need to wait until the prototype is ready before making any new suggestions or changes. Unless something is drastically wrong, or some data proves otherwise, stick with the prototype and discuss when it is ready.

Beyond shortening the "bring me a rock" exchange, a prototype clarifies ideas. When five people leave the idea meeting thinking of a rock, more often than not they are picturing five different rocks! Looking together at a prototype may result in a long list of changes, but the changes are defined and everyone is clear on what is being done and what to expect as a result.

Prototypes are also handy when people do not even know the type of rock they want You might explain the rock five different ways, but until someone sees it, it might as well not exist!

E: "It's a round, smooth, gray rock about the size of a grapefruit."
IP: "I've never seen that before."
E: "I haven't built it yet. Just try to imagine it."
IP: <blank stare/>

Great explanations and ideas will only go so far. At some point it needs to be tangible. And once it is tangible, people can actually engage in the conversation.

Hopefully bringing rocks and asking for rocks will be part of you future. Just remember that prototype type rocks are better. For everyone.

No comments:

Post a Comment