Throw-away prototyping

Throw-away prototyping is about creating, as fast as possible, a part of the future application to either ensure a feature is technically feasible or to show the feature to stakeholders or potential users in order to gather feedback from them.

Since the source code of this prototype is not reused later when developing the application itself, it makes it a throw-away prototype. Knowing that it’s a throw-away code helps focusing on the actual feature, while leaving aside aspects such as maintainability of the code, style, design patterns or testing. This makes it possible to finish the prototype very fast, without affecting negatively the technical debt of the final product.

Throw-away prototyping is different from sketching. Sketching is more graphical and oriented towards user interfaces and user experience, and doesn’t consist of writing programming code. Throw-away prototyping is usually used when sketching is not enough (for example when you need to show how a feature will perform on different smartphones or when you need to show the actual performance and responsiveness).

Throw-away prototyping can present a risk when dealing with stakeholders without technical background and in a context of tight deadlines and very limited resources: stakeholders may try to convince you to reuse in the final product the source code from the prototype. It is natural to believe that it will shorten the time required to release the product, but actually, it will only delay the shipment date. One way to prevent this is to use for the prototype a language which can’t be used in production (for example use C# when you know that the final product will be hosted on Linux servers with only Python installed).

^{Fig. 1: Throw-away prototyping and sketching : prototypes help gathering early feedback before starting developing the actual feature.}

Evolutionary prototyping

Evolutionary prototyping consists of building a prototype which is then refined based on the regular feedback from the stakeholders or potential users.

Here, maintainability of the code, style, design patterns or testing count from the beginning, which makes it possible to evolve the prototype into a fully featured, enterprise-grade product. The earlier steps of the prototype contain only the core part of the future product, and then, features are added progressively.

^{Fig. 2: Evolutionary prototyping : features are aggregated to the prototype to build the final product.}

Evolutionary prototyping is different from incremental prototyping. Incremental prototyping consists of building several prototypes, each one representing a part of the future system, and then combine them. Evolutionary prototyping is closer to Agile: often, you will be able to obtain early a working product with limited features and extend it until stakeholder have money. Incremental prototyping, on the other hand, is better suited for large projects with many contributing teams, each team working on a separate prototype.

^{Fig. 3: Incremental prototyping : several prototypes are combined to form the final product.}

Evolutionary prototyping is different from Agile methodologies too. Agile is about iterations and frequent milestones where a fully functional product can be released to manufacturing. If you have a working product every Thursday, you’re doing Agile. In evolutionary prototyping, you expand the prototype, but nothing forces you to have a fully-functional product regularly. You can spend two months creating the first prototype, than expand it with a few features in respectively two and three days, and then spend three months on another feature. You can’t have this sort of irregular patterns in Agile.

Specific Agile methodologies enforce additional rules. For example, if you don’t do pair programming, you can’t assert that you’re doing Extreme Programming. If your team don’t have daily meetings, you’re not doing Scrum.

Prototyping is used for many reasons. Maybe you want to gauge the user experience to a new application to estimate whether it’s worth building, without incurring the expense of actually building it. Maybe you need something that talks to an existing program over the network to perform integration or load tests on your network, before you’ve had time to finish the actual software running on your node. Maybe you need to show your investors something that looks almost like a finished program so that they’ll be more willing to come up with the investment needed to actually finish the program. (This has nothing to do with deception. Users and managers judge software solely by its interface, so it’s important to present them with a good interface so that they will believe the project is as far along as it actually is.)

A throwaway prototype is simply one that will not be incrementally transformed into the actual solution, but replaced by a new-written one. Obviously there is some waste involved in throwing away code that already does at least some of what you want, but the better architectural integrity of the proper code can easily offset that disadvantage.