To prototype or not to prototype

All engineering disciplines frequently use scaled down models to prove a concept before actually building something real or the real thing. This is the case, be it related to building architecture, bridges or aircraft manufacturing. So what about software? As an answer comes up the word, prototyping. The question is whether to or not to prototype? The question deserves special attention in software domain. This is due to the following reasons. First, software is created by developers who are unfortunately not the end-users of the product. Second, the end-user is not usually involved in specifying what they want, be it to see, type in or interact. In addition to that, the so called requirements get passed through quite a lot of hands and is perused and interpreted by the lot too. The funny thing is that, each will have an idea of what needs to be done, let alone how and with what. When this comes to the developer again there will be an interpretation of what is to be done. Finally, what the user wants is in his/her head and cannot be elicited in one go or so. The end result of this can be an unhappy user who thinks the software is useless or an irritated client who thinks the real objective was not met. For the developer this result can manifest as anything from, burning down new screens the user wants, dealing with the so called ‘changes’ to re-doing the whole thing.

If you have been in any of the above situation then you need to think of prototyping. First about what benefits it brings. Prototyping can help in the following ways

- If your team has thought of a concept which is core to building the solution. Prototyping can help in proving this concept. If the prototype proves your concept wrong, then you are in a position to plan accordingly rather than having to re-trace in the middle of development. It can also uncover any mistakes in your concept.

- You might have designed the solution with application layers and so on. Prototyping would be helpful in making sure things will get along as they were planned in the first place. If things do get along, you have something to look at when you build the real thing, a distinct advantage.

- It can help in comparing technologies that can be utilized to deliver a solution.

- You can identify bottle necks earlier which otherwise unnoticed will surface as impediments. i.e you make things as risk free as possible at an early stage.

- Above all, the user/client when presented with the prototype will start talking more than you expected. You will get a clear idea of ‘what they want to see’ and how they want to interact with the solution. I.e your interface will be change-proof as much as possible. There will be a better understanding between the two.

As for the downside of prototyping, besides the fact that it takes time, there is nothing horribly wrong with the idea at all. The problem stems from the fact that, not many people in the field understand the need to prototype and if they do, they lack the knowledge of how to prototype. The followers of the perfect world of waterfall model where things go in order or anything similar fall into this category.

In short, prototyping does help a software development team to move in the right direction based on facts and deliver what the user wants in the first go itself. i.e if you have not been able to deliver the right product in the first pass, you should think about prototyping.