Some think prototypes aren't needed, but they can save time, money, and headaches on your project. Choosing the right prototype helps both the development effort and the business side of a project.
Some companies view prototypes as a waste of time, but a working representation of a project’s solution can save time and money and reduce problems at all stages of development. Prototypes help you gather requirements and demonstrate architecture long before you’ve locked into actual application code. They also ease clients’ anxieties about large projects, and they can help some clients make decisions and commitments.
As with everything, there are various schools of thought on prototyping.
In some cases, lightweight programming or scripting languages can quickly demonstrate a project’s architecture, functionality, and interfaces. This kind of pseudo-solution prototyping proves design viability for complicated, long-term projects, and it can be helpful as a “go/no go” indicator for clients.
Framework prototyping uses mock-ups to represent functionality in the same technology as the project solution, with dialogue boxes and screens serving as holders for actual code. This kind of prototype is useful for nailing down requirements or getting a first look at an unfamiliar solution.
Reiterative prototype development methodology is another common approach. The prototype is refined through various stages until it eventually evolves into the desired product. This can be a failsafe method for rapid development, or it can provide planned stopping points in a staged rollout.
Each prototype represents vastly different goals and requires varying degrees of investment, and each affects the development methodology in different ways. It’s up to the architect, business driver, project manager, and sometimes even the client to decide if a prototype is necessary and what kind will be used.
Deciding on a prototype style
Prototyping is an exercise in risk management and development facilitation, and it minimizes the chances of producing the wrong functionality or an illogical design. Several factors must be considered when deciding if you should propose a prototype, and if so, which route to follow.
Has your team previously developed a similar solution?
If not, have your “A” team create a framework prototype to demonstrate the solution. Using this as the first phase in a project will uncover questions that would otherwise show up down the line.
Does your client have a problem making decisions?
If so, you can use a framework prototype to show your client what decisions need to be made, or use a reiterative prototype methodology if you suspect frequent, sweeping changes will affect your development process.
Do you have a large development team?
If so, use a pseudo-solution prototype or a framework prototype as a map for ongoing development. This facilitates development management by going beyond specifications to provide an actual model of the desired outcome.
Do you have "too many cooks"?
Choosing one or two people to develop a prototype of any kind will create a focused definition of how the application should look upon completion. It provides an outline that should be followed during development, and it can help keep everyone on the same path.
Is the client afraid to commit to a very large development effort?
Propose a pseudo-solution prototype. Using a scripting language allows you to quickly produce a lightweight solution that can represent the whole application, but without all the bells and whistles. Often a client will agree to pay for such a model before committing to the development of a large and expensive application.
Do you need to show working functionality during development?
A reiterative development process creates stopping points that show progress. A variety of formal methodologies support this style of development. Reiterative prototype development focuses on creating an entire representation of the solution and adding layers of refinement for each release. Complete system testing is performed at each stopping point, so the system is fully functional at each stage.
As you can see, many development situations warrant a prototype. However, once you’ve decided to move forward with a model, there are some “gotchas” to consider.
When moving forward with prototype development, it’s important to keep sight of the goals. If you’re demonstrating interfaces, make sure it’s the primary function. If you’re modeling architecture, make it a true representation of the final application.
It’s very easy to get caught up in the instant gratification of a prototype and include far more functionality or design elements than intended or needed. This can drag out the prototyping phase far too long and bring too little benefit to the solution. If you didn’t intend to demonstrate a functionality, then be disciplined enough not to include it.
If you aren’t clear on why you’re prototyping, it can easily become the waste of resources that business drivers predicted. Keep it simple, make sure all intentions are clear, and don’t let the thrill of very rapid development become a means to an end.
Demonstrate how prototypes save money
One of the most difficult tasks in creating a prototype is getting permission to do it. The time and money prototyping can save aren’t always obvious to business drivers and clients, but it’s easy to prove the value if a prototype is truly warranted.
While some might argue that prototyping creates rework, its purpose is to actually avoid the rework that comes from unknowns or incomplete design. Once you’ve got a model to work from, it’s easier to make the architectural decisions that arise during development. A physical representation can help waffling clients make decisions so development can begin with confidence in the desired outcome.
A proof of concept helps in high-risk solutions by identifying problems early so you can modify the architecture before they reach the point that you’d have to modify the code base to fix them.
You can demonstrate the importance of prototyping with a cost/benefit analysis. Outline the total development cost with and without the prototype. By creating an upfront model, your risk, development time, and probability of change will all drastically decrease.
Once you’ve shown that prototyping doesn’t incur new costs in most cases but it merely shifts some of the expenses of upfront planning, risk, and development to a new and focused effort, you’ll have an easier time convincing clients that it’s a worthwhile expense. It’s easy to show the benefits on large projects, considering the added bonuses of proof of concept and peace of mind that come with prototyping. If the concept of a prototype is hard for your client to swallow, outlining the benefits and explaining that prototyping is the bridge between planning and development can help them see it as a culmination point for efforts from different teams.
Prototypes are excellent, hands-on planning tools that are useful to anyone involved in a development effort. Being able to visualize an eventual solution provides a template for development and an easily grasped overview for business drivers and other nontechnical people involved in the project. A proof of concept can facilitate a project in everything from sales to quality assurance. If your solution warrants it, a prototype can help you design, develop, and deliver your product effectively and efficiently.
Prototypes: Time-saver or waste of time?
What’s your opinion of using prototypes to facilitate development? Share your thoughts in the discussion below, or send our editors an e-mail.