title: Breaking the Rules: Refining Prototypes Into Products  
author: Darren Bane  
copyright: 2020 Darren Bane, CC BY-SA  

# Abstract

Recommendations for a process to refine prototypes into production-quality code
are made.
\.R1
accumulate
\.R2

# Introduction

The conventional wisdom is that prototypes should be discarded once the lessons
have been learned,
and the final product written again from scratch.
In the spirit of
\.[
beck 1999
\.]
I argue that improvements in development tools have
invalidated this.

*Colophon*: this document tries to depend only on GFM,
in the same spirit as the software.
The use of tools like
PP, PlantUML and Pandoc is postponed indefinitely.

# Literature Review

There is a long history of recommending prototyping as a way to construct
systems.
I would personally recommend
\.[
robertson agust\(i 1999
\.]
and
\.[
pitman 1994
\.]
.

A closely related are is that of "specification animation",
quickly writing an implementation of some subset of a formal specification in
for example Z or VDM.
Prolog is a common choice for this, but I choose Lisp instead.

However, as stated in the introduction, this document differs from these in
arguing that it is possible to *refine* a prototype into a product.

# Prototyping

The first step is to construct a prototype,
or in modern terminology a "Minimal Viable Product".
These recommendations follow on from
\.[
robertson agust\(i 1999
\.]
and
\.[
bane 2008
\.]
.

Reasons for choosing ISLisp include:

* Procedural and object-oriented programming is commonly taught.
  And seems to be easier to learn.
* A disregard for popularity (which Common Lisp, or Java would win).
  In fact, the language seems more popular in France and Japan than
  the USA.
* The efficiency gain from an integrated environment.
  With Emacs and JSON-RPC it's not totally integrated, but is close.
  ELisp and ISLisp are not identical but are very similar.
* Contrary to a lot of other languages, it is fairly paradigm-agnostic.

Unlike Prolog,
users may end up writing logic eventually for DbC
but there is no need to force it at the start.

A JSON-RPC library was not difficult to write.

## Imperative/Object-oriented paradigm

Here, the following technology is recommended:

* The OpenLisp interpreter.
* Emacs for the view layer
* JSON-RPC for inter-process communication

Even though this is a prototype, attention should be paid to basic craftsmanship:

* Divide the system into packages, using at least the subset of CL that is
  supported by OpenLisp
* Write one-sentence comments for at least each public fun and class
* Use `assure`
  to check the types of parameters in public interfaces
* Some minimal documentation, at least an overview README file and man pages.

### Further work

This is probably the most work that makes sense
without earning money.

* Write contracts for public funs & classes
* Could do simple multi-user,
  using the IRCv3 bots (nickserv, chanserv) and IRCCloud or similar

# Refinement to Production-Quality

I argue that there is a repeatable procedure to improve the quality of a
(reasonably well-written) prototype to a releaseable product.

First, ensure that the surrounding infrastructure is in place:

* Configuration management. The prototype should already have been checked into git.
* Build. TODO: Read the recommendations in the OpenLisp manual?
* Test.
  Write olunit
  test cases for any scenarios that aren't coverered by DbC.
* Track. Start using a defect tracking system.

Then, the following code & documentation improvements should be made:

* Document the system more exhaustively
* Port some of the trivial-\* CL libraries from quicklisp where justified.
* Port to core-lisp on platform.sh?

# Conclusion

A method for developing software from an incomplete understanding of the requirements is given.
It is hoped that this is more effective than most of what is currently-used.
\.[
$LIST$
\.]