I believe in the power of prototypes. That is to say, I want to see an idea in action before I feel comfortable of its existence and the soundness its being. A few years back when I first started a career as engineer, I learned a valuable lesson. After making modifications based on a requirement and checked code into SourceSafe (a Microsoft source control product), I thought all was well, until a senior team member called on me. Part of his job was to mentor and supervise my work. He asked to review the change. So we sat down side by side. I showed him and he said it was a good job. Then he said,"Not that I don't trust you. It's just my thing that I need to see things with my own eyes in order to believe."
Fast forward to now, after 20 years doing software development and project management, I am leaning more and more towards this "seeing things with my own eyes" mentality. Maybe it is an age thing. But considering the complexity of a software application these days and the precision it requires, being conservative is a good trait.
Prototype, or proof-of-concept (POC), is a wonderful thing. In my opinion it serves four important functions:
It proves the concept. Nothing is more valuable than knowing the path in mind is not a dead end. This applies in particular to those projects that have large share of uncertainties. Taking a trip to Mars is not mind-boggling if you know your friend John has just traveled there and back. But if you were the first one sent to Mars, oh boy.
It formulates a design. Over the process of building a prototype, key components will be researched, evaluated, adopted, developed, integrated and tested. System boundaries will emerge. Key functions and services will be grouped into at least three tiers: low-hanging fruits, hard but do-ables, and dont-know-hows. This knowledge, in turn, will drive task priorities, task estimation, and risk evaluation. All these will become a cornerstone of the system design so it will be practical, executable, and working.
It builds communication. Building prototypes involves lots of discussions. Clients brain dumps their expectations to dev team, while dev team internalizes those business functions into a coherent picture illustrated using their familiar technology jargon. Details that hold importance but have been neglected will be discovered and ironed out. A common knowledge base and a common vocabulary will be built over the course. Instead of business syntax on one side (requirements) while some technology jargon on the other (SQL? Queue?), we now have a vocabulary that all could understand, contribute, and use to effectively communicate. This reminds me a strategy by Starbucks. Their staff will repeat a customer's order in a particular sequence:
- Hot or iced.
- Number of shots (if any extra)
- Number of pumps of syrup (if you're that specific)
- Type of milk.
- Any extras (mo' whip, mo' deliciousness)
- Drink type (latte, Frappuccino, etc.)
Why do they do that? To build a common a vocabulary and to improve communication. The result, less error and happier customer.
It removes risks. Hiccups will be discovered early on in the game; workarounds will be put in place; strategies will be clarified; team knowledge will be shared; and collaboration will be formed and adapted. Let's put it this way: if a POC did not work out, whether it be because of technical challenge or organizational barrier, the full-blown project is not gonna succeed.
So next time you have an exciting idea that will dominate the world, take that drawing on napkin to build a prototype, because as the old saying, seeing is believing.
— by Feng Xia