The philosophy of a prototype

Prototypes are something every software developer comes across in his lifetime. Usually quite informal in the early stages of their career by coding by the trail-and-error-pattern where every iteration can be seen as a prototype for the next. Later on, with projects getting bigger, it is most likely that the programmer starts to use prototypes more systematically. Some even learn to formalize them and use them in a professional way. In the end, software developers can be categorized in two groups:

  1. Those who see prototypes as a build-product in early stages of software development which improves project quality and resource planning by testing certain aspects and/or try new methods to create the product and which must be thrown away before the actual project is started to reach best possible product quality
  2. Those who do not care so much about all these words and just like to code straight away

From how I wrote this, you might get an idea which philosophy of those both I personally prefer. But I’m not one of those who take the proceeding too seriously. I regard the prototype as a piece of software which I use to analyze and gain information to compensate missing knowledge. This might be because I want to learn about a new technology or because I want to try new tools. Or because I never worked on a similar project before – which should be quite usual for a ambitious software developer. But I do not regard it necessary to create a prototype for really every project I work on. Sometimes it is possible to just determine one.

As the experience of the engineer increases, it is sometimes possible to find old projects which just can be looked at from another new point at view. Or it is possible to find another project which fulfills similar aspects to what one intends to work on. This approach however requires a highly skilled engineer as it is a difficult task to gain knowledge from a foreign codebase. Especially if the requirements or the design of the foreign project was not documented. This is sadly quite often the case in available open-source projects. In this case the gain of knowledge is close to zero.