Software Prototyping – Part 2: Throw Away or Evolve?

In the first part of this article we discussed the difference between functional and user interface prototypes.  In this one we’ll discuss whether your prototype should have a role beyond the discovery and design phase.

Throwaway PrototypesPeople often talk about “Throwaway Prototypes” versus “Evolutionary Prototypes” and it’s very important to understand the difference and exactly what type you are creating before you begin.

Throwaway Prototypes

A Throwaway Prototype, as the name suggests, forms no part of the final application. Its purpose is to prove (or disprove) a design and get approval for actual implementation.

It can be produced using any quick and dirty technique and the quality can even be quite poor, so long as it satisfies the requirements of identifying what’s right about a design, what’s wrong and what’s missing.

Because of the speed at which Throwaway Prototypes can be put together and changed (usually on-the-fly), they encourage feedback and continual revision until the design is about right.

Because the effort required to produce them is relatively small, there’s less ‘attachment’ to a design and therefore very little reluctance to change. However, you do need to be careful that you don’t end up in an endless cycle of analysis and revision without making any development progress at all!

Evolutionary Prototypes

In contrast, Evolutionary Prototypes are intended, right from the start, to eventually evolve into the final, delivered application (or system) through incremental developments and changes. In one sense, this seems like a great idea because each increment is getting you closer to a delivery and progress is clearly being made.

However, there are many risks involved in this approach. Because it involves implementation of the system itself, the coding has to be of production quality from the start. The idea of ‘cleaning it up later’ is a very bad one since this will never happen in practice, leading to potential problems and instability later on. But this conflicts with one of the key benefits of being able to create prototypes quickly. Also, because of the effort that’s gone into it, there can become too much attachment to the implementation which leads to a resistance to change.

Not only that, it’s very difficult to see the ‘bigger picture’ with an evolutionary prototype because you can only see, and therefore review, the parts that have been implemented and it’s very difficult to compare different versions or approaches to a given design.

There’s another potential problem with evolutionary prototypes. Sometimes you’ll already know what technology you’ll be using but sometimes you will be free to choose what’s best for the application. By creating an evolutionary prototype you will be committing to an implementation too early when a more suitable technology or component set might become apparent later on once the requirements of the application are better understood.

In the last part of this article we’ll discuss different methods and tools for generating prototypes.

Related Posts Plugin for WordPress, Blogger...

Tags: ,

7 Responses to “Software Prototyping – Part 2: Throw Away or Evolve?”

  1. It?s good to see you make postings on this topic, I have to bookmark this web site. Keep up the good work.

  2. [...] This post was mentioned on Twitter by Jan Jursa, brian_henderson. brian_henderson said: RT@IATV Good article: "Software Prototyping – Part 2: Throw Away or Evolve?" http://bit.ly/8JLB0f (carettasoftware.com) [...]

  3. Justin McNeal says:

    Good Article. I agree with everything that you’ve stated. I am a big fan of throw-away prototypes, however if you have dedicated development resources, and an architecture that is constrained to a specific set of tools/languages, then an evolutionary prototype can be the best model. Keep the articles coming. Thank you.

  4. Jonathan says:

    Thanks for your comment, Justin.

    Even with dedicated development resources and constraints on the architecture or tools (that will almost certainly be present once an application moves into actual implementation and beyond ‘version 1′), I think that the very nature of evolutionary development without some sort of up-front throw-away prototyping will miss opportunities for a better design.

    Presenting and evaluating multiple alternatives can be very tricky when you’re building them into the application itself whereas a lot can be explored and learned even from quick sketches on paper.

    All the best,
    Jonathan

  5. [...] has its own language. One example of this product speak is the term product champion. ManySoftware Prototyping Part 2: Throw Away or Evolve …… the final, delivered application (or system) through incremental developments and changes. … [...]

  6. lanbede says:

    “Because it involves implementation of the system itself, the coding has to be of production quality from the start. The idea of ‘cleaning it up later’ is a very bad one since this will never happen in practice, leading to potential problems and instability later on. But this conflicts with one of the key benefits of being able to create prototypes quickly. Also, because of the effort that’s gone into it, there can become too much attachment to the implementation which leads to a resistance to change.”
    You can see more about that?

  7. I’m extremely impressed along with your writing skills and also with the format in your weblog. Is this a paid topic or did you customize it your self? Either way keep up the excellent high quality writing, it’s uncommon to peer a nice blog like this one these days..