It’s time again for an I. M. Wright podcast from the illustrious man’s archives. This podcast is for the August 2008 blog post, which begins like this:
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?
You can get the podcast here.
And we encourage you to check out I. M. Wright’s “Hard Code.” The book includes numerous “Eric Asides” by Wright’s alter ego, Eric Brechner, Director of Development Excellence in Microsoft’s Engineering Excellence group. These asides explain Microsoft terms, provide updates, or convey additional context. Wright’s blog does this too.