Prototypically Speaking – The Software and Requirements Prototyping Blog

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!