When not to prototype

As you will no doubt have realised by now, we’re incredibly keen on the whole concept of software prototyping. It’s something that, once you’ve seen the light, is difficult to get out of your system – and with good reason. It’s empowering, flexible, responsive and provides the sort of feedback into the design and development process that traditional methods lack.

However, it would be wrong to suggest that prototyping is the answer to all problems – it isn’t – or that indeed it can apply to all projects – it can’t.

For that reason, here are a few cases where the use of prototyping may not be the best choice, or even a valid choice at all:

  • Scale

    For the very smallest projects, creating a prototype might well be an investment in time and effort that is unnecessary and which may not be able to recover its own costs in subsequent savings;

  • Interactivity

    Prototyping excels at providing feedback about systems with which users interact. So, it goes without saying that non-interactive systems such as system batch jobs, services or data aggregation tasks may not benefit much from a visual prototype. This isn’t to say there is no benefit at all – the very task of visualising any system forces us to focus and to ask questions – but again it is unlikely that the cost of prototyping would be recovered by any savings;

  • Nebulosity

    If a system lacks even a basic scope and purpose, it will be incredibly difficult to create a prototype of any value. If a customer doesn’t have a clear vision of what they aim to achieve and some preference as to how that might be accomplished, it would be better to perform some early brainstorming sessions and conduct a little more research before starting any prototyping activity;

  • Specificity

    Conversely, if a system is already fully specified, had been rigorously designed to the last detail, and especially if the business stakeholders are happy with the specification and design, it may be unnecessary to create a prototype. There may be value in having a demonstrable model, of course, but in terms of using the prototype as a vehicle for soliciting feedback, its value is diminished.

There are, of course, other valid reasons why one might avoid creating a prototype, but they are overshadowed by the number one reason why people don’t prototype: awareness. Yes, lack of awareness of the process and benefits of software prototyping is the most common reason why people don’t do it.

Which is, in a roundabout way, the Raison d’ĂȘtre for this blog!

[digg=http://digg.com/programming/When_not_to_use_software_prototyping]

About John Clark

My name is John Clark and I previously ran a software house called Reynard Thomson, from which this blog originally grew. In the meantime, we launched a video-based user testing service (Kupima) which didn't really take off, and I have since moved into a new field specialising on software-based research & development consultancy. I'm active on LinkedIn, and would love to connect to anyone who has an interest in software prototyping or R&D: http://uk.linkedin.com/in/jtclarkuk/
This entry was posted in General Business, Prototyping and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>