What is throw-away prototyping model in software engineering and why do we need it? How does it differentiate from Evolutionary Prototyping?
Why we need Throw-away Prototyping?
development process;prototyping
Throw-away prototypingThrow-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 prototypingEvolutionary 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.