Why not just make the darn thing.
+4
A:
A prototype is a playground, if you will. You can test things out, throw them away if they don't work out; iteratively find out how things might work with real users, etc.
Prototypes test specific aspects that are unclear or not yet fully determined and as such are easier to implement on their own than trying to figure out how to integrate something you don't quite know yet into a complete system. This also means that it doesn't hurt too much when throwing them away.
It's not uncommon to implement prototypes without any actual programming. Paper prototypes and interactive PowerPoint slides are examples of that.
Joey
2010-04-02 19:52:09
It is also quite common for prototypes to become production code. Makes me cringe but it happens all the time.
Byron Whitlock
2010-04-02 19:59:10
Well, there are processes that *do* work that way. IBM's “Iterative development in the field” for example (although they chose to call it “proto-application” to mark the distinction to a prototype). How it *should* be usually, though, is that the prototype remains separate from production code ... yet as you noted, that's sadly not how it always ends.
Joey
2010-04-02 20:00:59
+1
A:
Writing production-quality software requires a lot of effort in all areas of the project. If there is a specific part of the system that might be very hard - or even impossible - to implement it is a good idea to write a prototype that displays that it is possible to the solve the problem. When it is known that the problem can be solved, it is more acceptable to spend the time needed to write real production-quality software.
A prototype may also be a way to show a concept to users, which is otherwise hard to explain. In that case the prototype focuses on showing the key features of the concept, but it may e.g. show static data instead of real calculations.
Anders Abel
2010-04-02 19:52:53
+1
A:
Typically when coding up a prototype you may be a little less careful with your testing and coding standards. The object is to quickly get something working to prove the concept or start a discussion on various aspects of the project. If you determine that it isn't feasible or decide to go in a different direction you've put in less effort to get the decision. Prototypes have a different standard of quality than a finished (or in-progress) product.
Sometimes you will take the prototype and simply refactor it into the actual product. It really depends on how carefully structured the prototype is. Often is best just to use the prototype as the concept and start over, building the real app using your regular process and standards. That way you're product isn't "infected" with the short cuts you took in getting the prototype out quickly. It's also harder to be sure that you've tested adequately when retrofitting a prototype with unit tests because it's much easier to simply write the few "normal" case tests and let it go at that, especially if the code as written is difficult to test. Writing the tests before the code and using coverage analysis helps to make sure that you've both adequately tested it and thought through the design from a testability perspective.
tvanfosson
2010-04-02 19:56:16
A:
Because coding the damn thing could take many years while a prototype could be done in minutes/hours/days
Jimmy
2010-04-02 20:16:27