What is throw-away prototyping model in software engineering and why do we need it? How does it differentiate from Evolutionary Prototyping?

  • 5
    There's an old joke/guideline that all software sucks until version 3. The first version is figuring out what you need, the second is figuring out how to do it (well). – Telastyn Aug 17 '14 at 14:12
  • 2
    You can read more about it in a book called "Rapid Development", Steve McConnell. And maybe "Mythical man month" if history of software development interests you. – andrew.fox Aug 17 '14 at 15:12
  • 2
    @andrew.fox "Build One to Throw Away" is useful to have in context (wired.com/2010/07/ff_fred_brooks ) - "When I first wrote The Mythical Man-Month in 1975, I counseled programmers to “throw the first version away,” then build a second one." – user40980 Aug 17 '14 at 18:17
  • @MichaelT, yes, as far as I remember, it is in the book's appendix (the newest edition). – andrew.fox Aug 18 '14 at 20:13
  • 1
    @Telastyn I don't think that's a joke. – RubberDuck Feb 6 '16 at 18:50
up vote 17 down vote accepted

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).

enter image description here

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.

enter image description here

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.

enter image description here

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.

  • So the main difference between agile and evolutionary prototyping is that in agile prototypes follow release cycle with a fixed length? – Giorgio Aug 25 '14 at 10:10
  • @Giorgio: as I explained in my answer, the differences are: (1) release cycle with a fixed length, (2) short iterations, (3) fully-functional product at the end of each iteration and (4) additional rules for specific Agile methodologies. IMO, there is no "main" difference among those four. – Arseni Mourzenko Aug 25 '14 at 10:29
  • Since additional rules apply only to specific Agile methodologies, (4) does not characterize Agile. E.g., pair-programming does not characterize Agile. Furthermore, to me (1) seems to imply (3): if you release something it must be a fully-functional product, or is it possible to release a non-fully functional prototype in evolutionary prototyping? (2) is also important: iterations should be short whereas I guess in evolutionary prototyping there is freedom to choose long or short iterations. So, it seems to me that (1) and (2) characterize Agile (I had forgotten (2) in my previous comment). – Giorgio Aug 25 '14 at 10:47
  • But maybe I am wrong because I have interpreted (3) and (4) the wrong way. – Giorgio Aug 25 '14 at 10:48
  • @Giorgio: "if you release something it must be a fully-functional product" Not necessarily. When you release a prototype, it is not a fully-functional product, since some features actually available to end users may be completely broken. As for (4), I agree with you, it doesn't characterize Agile itself. – Arseni Mourzenko Aug 25 '14 at 11:46

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.