Rapid prototyping is a software development method that aims to clarify open questions at the start of a software project as quickly as possible. It is used to find the most solid basis possible for further developments at the lowest possible cost and to uncover the ‘unknown unknowns’.

Different Product Management Strategies

At the start of a software project, many aspects are often unclear, especially those relating to the software itself. Questions about efficiency, architecture, data volume and the data structures themselves can often only be answered during the implementation itself. This was already known in the early days of software engineering, as Winston Royce explained in his presentation of the waterfall model (Royce, Winston (1970), ‘Managing the Development of Large Software Systems’ (PDF), Proceedings of IEEE WESCON, 26), where numerous loops and feedback mechanisms are added to the naive flow of a development project. However, the earlier a problem can be found (and fixed), the less costly it is. If, for example, a fundamental error is only recognised during operation, a time-consuming and costly redevelopment may be necessary. Many modern development methods, especially agile development, aim to recognise and answer problems and open questions at an early stage and to incorporate the new information found in this way into the development process.

In addition, unknown issues are discovered in the course of every software project, i.e. issues that were not visible during planning and therefore could not be solved. This can arise from properties of the environment, the components used, the architecture, user expectations or simply from the fundamental properties of the problem to be solved.

Structure First

One such method is rapid prototyping. This involves determining the status of a development and formulating open questions: ‘What can the data structure look like?’, ‘Which views or analyses are necessary for the user?’, or ‘Which data must be recorded in order to create additional benefits?’. These questions are then used to develop a prototype in the shortest possible time and to the exclusion of all other aspects, which can provide clarity in this regard. The two characteristics already mentioned in the title are central: ‘rapid’, i.e. in the shortest possible time; and ‘prototype’, i.e. not a complete system but only a design pattern, a template model. Both aspects of this method indicate that other criteria do not play a role: Maintainability, extensibility, operational properties, security, testability, documentation, etc. Only the quick answering of the formulated questions (and the additional discovery of new, unknown questions) plays a role here. The knowledge and answers gained here can then flow into a design or implementation, inform it and thus ensure that a ‘correct’ implementation can avoid the errors and problems found.

If a prototype cannot answer the questions, it is of course worthless; the development of a rapid prototype must \textit{always} point to the goal of clearly formulated questions and must not deviate from or go beyond them. It is too easy to fall into this trap and develop a prototype that can do everything - but at the same time answers nothing and generates many costs. Unfortunately, inexperienced teams often lack the necessary discipline to develop a prototype in a focussed, efficient and effective manner.

Now it is tempting, with such a prototype in hand, which was produced in a very short time, to ask \textit{what is still missing?} From a user's point of view, there is already a ‘solution’ to the problem in the form of software, and at a fantastically low cost. But just as nobody would want to take a flight in an aeroplane prototype, nobody should use a software prototype as a finished product. The already mentioned aspects of security, maintainability, testability, documentation, etc. are all important. \textit{is} missing here, on purpose, and is consequently missing in product situations. These facets of software development are extremely important for high-quality software, but are specifically omitted here in order to achieve clarity.\\

Again, an experienced team with trained discipline is required to use the lessons learnt from a prototype, but not the prototype itself.

The rapid prototyping method therefore strengthens a software project, leads to significantly higher quality in the end product and thus ensures lower costs overall.