Building prototypes (if necessary) is considered best practice as far as software construction is concerned. Its usefulness lies in the lesson learned which can be applied later on. Therefore, you can develope prototypes in order to validate your architecture, testing performance aspects, selecting the right technology and so on.
So far so good. However, you must know the fundamentals of software prototyping:
- Partial functionality. Your prototype shouldn’t have all features. After all you’re trying to validate just one aspect of your future product, otherwise your working on a early version of your product.
- Doesn’t meet your quality standards. Since a prototype is not a product, there’s no point in making it perfect. Moreover, you need it to make a decision so you want it finished ASAP.
- Disposable. Because of point 2.
- You’re prototyping and that is crystal clear. Stakeholders (particularly managers and clients) must understand you’re working on something disposable.
- It’s part of your planning sheet. So everybody knows you’re going to spend some time on it.
If your so-called “prototype” breaks any of the rules mentioned above, it’s more than likely that it has nothing to do with a prototype. If this is your case:
- Do no refer to it as a prototype, call it anything. You’ll save yourself a lot of trouble.
- Ponder using any of those incremental methodologies.
To sum up, just keep in mind the following:
It’s a prototype.
It isn’t.
_______________________________________________________________
0 Responses to “Call It Anything”