Prototyping is a #Software Development Practices which is cheap and fast to be developed as typical prototype usually ignores most of the details such as correctness (using dummy data), completeness (may function only in a very limited sense, only work on a given input data or only one menu item available), robustness (incomplete error checking, great crashing possibility) and style (little to no comments and/or documentation). [The Pragmatic Programmer](lit/@Hunt1999)❌
The prototype developed could be either code-based (in higher level language such as #python, #perl, Tcl, Tcl/Tk, Visual Basic, Powerbuilder or Delphi) or just written down to sticky notes. Sticky notes are great to illustrate something dynamic, such as workflow and application logic. Sometimes, drawing can be another way to develop the prototype, especially when focuses on user interface. In the end, the form of the prototype taken into doesn’t matter, as it served only for learning and to answer just a few questions. As such, it is meant to be disposed afterwards. Trying to incorporate it directly into the production environment can be a grave mistake.
Prototyping could be especially helpful when you want to test something out or just to clear your mind. If you are not sure whether the project is sound or it is just your procrastination, developing a prototype for it is a great time. If you felt you are wasting time on it, then there is probably nothing to worry about the project. However, if as the time goes, your doubts has been solidified into crystallised arguments based on the observation, that you know that some premises or assumptions are wrong in the prototype, then show it to your team and decide whether to improve the model or simply don’t waste time on it. [The Pragmatic Programmer](lit/@Hunt1999)❌
The following shows things that could be prototyped:
- Architecture
- New functionality in an existing system
- Structure or contents or external data
- Third-party tools or components
- Performance issues
- User interface design
Note: When building a prototype for architecture, we should inspect on how the system hangs together as a whole in a higher level. Turn our focus on the major components’ responsibilities and collaboration between those to see whether they are well-defined and appropriate. Investigate the coupling (is it minimised?) of the architecture. Find out whether there are potential sources of duplication. Are the interface definitions and constraints acceptable? Pay attention to modules’ accessibility (access path and the access) to the data it needs during the program execution.
Note: Only develop prototype when necessary.