My experiment worked! (Prototyping)

It’s summertime. Time to sit out in the sun and daydream, perhaps on a vacation or a weekend afternoon. When your mind is relaxed at times like these, you often think of beautiful new ideas. You further develop those ideas and then, when the time is right, perhaps early in the next release cycle, you begin prototyping those beautiful notions. Before you know it, your beautiful ideas have blossomed into hideous, miserable nightmares that either die of exposure, or worse, live on to cause future generations of engineers to curse the day you were born.

Oh but if it were a fairly tale. Instead, more often than not, prototypes of beautiful ideas become horrific, hairy hodgepodges of hacks that cannot be easily maintained, refactored, or understood. Why? What happened?

It’s not that you should write prototypes more carefully, with unit tests and all the rest—you shouldn’t. It’s not that you should throw the prototypes away—though you should. No, the problem is that your entire philosophy about prototyping is dead wrong.

Explore the space

Usually, when engineers think of a new idea to try, they write a prototype. That’s a major mistake and the wrong thing to do. It leads you down a path to destruction of all that was good about your idea. You see, you shouldn’t write a prototype—you should write dozens of prototypes parameterized to try hundreds of cases, all designed to solve the same problem but from different angles.

That’s how all other fields of study work. You don’t do one experiment, try one approach, or use just your first guess. You do hundreds of experiments. Artists and producers call it, “exploring the space.” Could you imagine if medical researchers only tried one idea at a time to cure diseases? Wouldn’t you think that was idiotic? Hello?

That’s so rad!

Naturally, you don’t have all the time in the world to write dozens of sophisticated prototypes. Good, you’re not supposed to. Prototyping isn’t supposed to be like production engineering. It’s supposed to be like experimenting. It’s supposed to involve the software equivalents of duct tape, silly putty, and wire hangers, like VBScript, Word Art, and Perl. You’re supposed to throw together prototypes in hours not days.

If it’s taking you longer to write one prototype than it did to understand the problem, you are already off the end of the gangplank and are headed into the shark infested waters of failure and frustration. Spending serious time writing one prototype not only distracts you from exploring other possibilities, but it also puts so much investment in that one prototype that you can’t help but use it as the basis for production code. Welcome to despair and desolation.

On the contrary, prototypes should be churned out so fast and furiously that no one would consider taking them seriously as the real thing. Prototypes are there to try out ideas, make mistakes, iterate, and gain insight. If you only write one of them then you’ve learned nothing, aside from the fact that you are a close-minded, ignorant, misguided fool.

Harness in the good energy

Hold on, the “I can’t change” people are calling. They say, “You can’t prototype quickly without frameworks, harnesses, and libraries. It takes time to build those tools. Creating dozens of prototypes with our shipping pressures just isn’t realistic.” Look, if you are consigned to being a calcified carcass of a coder just admit it and accept it.

Otherwise, you need to wake up and realize that prototypes don’t have to follow the same rules as production code. They can be written in different languages and be built on different platforms. They can use tricks and shortcuts; scripts and canned animation; you name the kluge, short of stealing licensed code, and it’s fair game for prototypes.

There are loads of libraries, heaps of harnesses, and enough frameworks to fill a football field to help with rapid prototype development. All you need to do is step out of the box and into the garden.

You still have a choice

Great design, like great research, depends on trying dozens of ideas. It also relies on collaboration, working with others to generate new ideas and directions. If there’s a user interface (UI) involved, you want user experience (UX) folks to help inspire you. If it’s a library or API, you want architects or clients as your co-conspirators.

Once you’ve generated dozens of ideas, prototyped them all, iterated, and gained the desired insight, you’ve got a number of options. You can:

§  Pick your subjective favorite.

§  Use a simple tool like a Pugh Concept Selection Matrix to thoughtfully choose between alternatives.

§  Combine aspects of each approach and experiment some more.

§  Postpone making a decision till constraints force a choice.

Postponing design decisions till constraints force your hand is called “set-based design.” You keep all design options available, only culling ideas when they break a requirement. Because schedule requirements often hit before all alternatives have been considered, you eventually need to fall back on something like Pugh Concept Selection. Until you do, set-based design keeps your mind open and helps you find the optimal solution.

Throwing it all away

By the time you’ve made your design choice, your duct tape and bailing wire prototypes should be so fragile and convoluted that no one would consider keeping them for anything but nostalgia. That’s the right result.

Using cobbled-together code as the basis of production work only leads to software that is difficult to maintain, susceptible to failure, and must be retrofitted to meet quality requirements, such as automated tests, code reviews, globalization, accessibility, security, privacy, manageability, and performance just to name a few. The result of this retrofitting is the hideous hodgepodge of hacks I mentioned earlier. Not the beautiful ideas that started you down this path.

Throw away your prototypes, using them only for idea and algorithm reference, not code. This shouldn’t be painful because you spent so little time on each.

Temptations always come along

I know there is a great temptation to write solid prototype code using quality methods, just as there is a great temptation to write rapid production code using quick-and-dirty methods. You must avoid these temptations by any means necessary.

How you act and code during experimentation should not match how you act and code during production. People who don’t understand this difference have a name. They are called “children.”

If you are treating prototypes like production code, or vice-versa, you should get reamed on your review. If your boss thinks you should write prototypes like production code, or write production code like prototypes, he should be fired. Not that I feel strongly about it.

The result of production should be the on-time delivery of delightful customer experiences that meet a high quality bar. That’s what managers should reward you for during production.

The result of prototyping should be insight and innovation that changes how you think about your product, service, and customer. That’s what managers should reward you for during prototyping.

Do yourself a favor

The bottom line is that if you only write one prototype for your idea, you’ve done your idea, your team, your company, and yourself a disservice. You won’t discover all the implications of your idea, good and bad. You won’t discover new ways to implement your idea or expand upon it. You won’t discover all the uses for your idea or how it connects with other ideas. All you’ll have is your first guess. You’ll have cheated yourself and your idea.

Remember, it doesn’t take longer to implement dozens of prototypes—it takes a different mindset. Sure, you don’t want that mindset when you’re producing shipping products and services. But during the planning and experimentation phase, timely torrents of tossed-together trials are just what you need to “explore the space.” Who knows? Maybe you’ll make a few gold records of your own.