In software development there are always unknowns. Will this library work? How fast will this be? How long will this take to implement? One technique that can help address these questions is prototyping.

There are many different types and levels of prototyping, going all the way up to elaborate models that are almost like the finished product. There is even a development style called evolutionary prototyping in which a prototype is refined incrementally—moving closer and closer to the finished product until voila! it arrives.

In this article I’m going to discuss the type of prototype in which you write as little code as needed to prove that something will work, or to demonstrate a concept, or to answer a question. It’s frequently an investigation, and it usually results in code that is not production quality. It’s either thrown away or heavily reworked before seeing any real use.

WHEN SHOULD YOU PROTOTYPE?

Prototypes are most appropriate for well-defined questions that can be answered with a small number of hours (say fewer than 20). They are great for answering questions about interactions with third parties (whether libraries, components or services). They are less suited for answering questions about performance. Unless you are prototyping within an existing system, a prototype will rarely give you a “real world” performance, but it can help establish upper or lower performance bounds.

Even when working with third party libraries, prototyping is not always needed. Frequently you can answer questions about the library by looking at documentation or sample code, saving prototypes for more complex use cases.

ESTIMATION

One difficult aspect of prototyping is estimating how long it will take, especially when you are truly dealing with something unknown. In those circumstances I usually need a bucket of hours, say 10, in which to get started. After that I get a better understanding of the unknowns and am able to estimate the remaining effort required.

Furthermore, prototyping can help you estimate work that can’t easily be estimated otherwise. This includes work that you wouldn’t normally prototype. “How long will this take? I don’t know, let me spend a few hours and see how far I get, then I’ll let you know.”

EVALUATING MULTIPLE OPTIONS

Prototyping is great when you need to choose between multiple approaches or multiple libraries. Pick a suitably complex use case, and implement it with each possibility. You’ll know pretty quickly which approach is the easiest, most effective, or best meets your criteria.

HARDEST/RISKIEST FIRST

I worked on a project with a developer tasked with implementing custom reports using a third party report library. Most of our report requirements were simple, but we had one area that was complex. We needed a table of data with dynamic columns, complex headers and great flexibility. We didn’t know whether the library could handle our demands, and after 100 hours of development neither did the developer! He used a top down approach to the report content, starting with all of the easy bits first. What was really needed was to start with the hardest part first—to validate the library choice. We immediately switched to prototyping the data table and were able to prove the library was capable. We got lucky; going back to the drawing board after investing so much time would’ve been a big blow the budget.

Failing fast is the key here. If something is not going to work, you want to know as soon as possible.

IGNORE COSMETICS

When doing a prototype, you typically ignore any cosmetic niceties and focus on what you are investigating. Unless of course you are investigating something cosmetic like graphical capabilities or rendering speed! But the typical ugliness of prototypes can be a downside. Sometimes stakeholders can’t see past the rough interface and envision the final product. In projects like that, wireframes or graphics mockups with (or instead of) a prototype might be a better way to communicate with stakeholders. You can leave the prototype as an internal development team detail.

PROVE (OR DISPROVE) THE IMPOSSIBLE

I was recently tasked with doing a proof of concept to truly answer the question “is this even possible?” I had to write a control in .Net that would access a third party library to display video in a Visual Basic 6 client (using COM Interop, yuck!). You don’t want to know the details behind this; just give us the benefit of the doubt that this was in fact the simplest solution for our problem. At various points during the proof of concept it looked to be unworkable. I kept running into stumbling blocks and brick walls, but in the end it proved feasible. The proof of concept wasn’t clean, feature rich or useful for anything other than a ta-dah! demonstration, but it gave us the confidence to move forward with the plan.

Of course it could’ve easily gone the other way, and our approach could’ve failed. If I had spent a reasonable amount of time without proving success, we would’ve had to give up and go back to the drawing board, but at least the investment was low.

Judging whether to keep going or cut your losses is a decision that requires experience to make. Writing down the avenues you’ve investigated and getting another developer to review can help to see if there’s a possibility you haven’t thought of.

Bottom line: smart use of prototyping will save time and cost in the long run. You won’t regret it.