109
● Focus initial prototyping efforts on poorly understood or risky areas. Furthermore,
since prototyping quantitative methods consists of scientific experiments, be sure to
carefully monitor and control them.
● Consider performance in prototype design. Do not develop quick and dirty code for
the prototype. Risk rises when the prototype has significantly different performance
from the final working system. Prototyping is not an alternative to good design.
● Be sure management and the team leader understand the difference between a lim-
ited prototype and a full-scale, working product. Miscommunication can lead to a
risk of underbudgeting prototyping projects.
● Avoid digressions. Do not put too much work into prototyping and evolving any
piece of the trading system puzzle until you are certain it is going to remain part of
the production system.Visible work may be done quickly; other less visible work is what often takes time.
Low visibility work includes database access, maintenance of database integrity, security,
networking, and data conversion. The biggest risk is that a stakeholder will see a running
prototype and conclude that the product is nearly completed. The purpose of building a
prototype is to prove design aspects as early as possible, before resources are committed
to full-scale development. Proving can be iterative as well. We recommend the team look
for feedback through intrateam peer review and refine the prototype until everyone agrees
it is correct. They can be for:● User interfaces
● Interactive performance
● Real-time timing constraints
● Data sizing
● Proof of concept aspects.10.2.2. Throwaway Prototypes
In most cases, we recommend throwaway prototypes. In throwaway prototyping, the
product team develops code to explore factors critical to the system ’ s success, and then
that code is thrown away. Prototyping, both horizontal and vertical, uses tools such as
Excel or MATLAB; programming languages and development practices are much faster
compared to the implementation language and practices. When used as a requirements
specification aid, throwaway prototyping accelerates project development.^7
Throwaway prototyping delivers speed due to its ability to explore individual require-
ments, design, and implementation options quickly. The product team should employ
throwaway prototyping anytime where clarification of requirements is needed, to decide
on an architectural issue, to compare design or implementation options, or to test per-
formance optimization. One of the key problems in developing throwaway prototypes is
that the prototype might not get thrown away.
Throwaway prototypes must be discarded. Delivering an Excel prototype, for exam-
ple, will likely result in poor performance, poor maintainability, and poor design. Because
prototypes emphasize quick implementation at the expense of robustness, reliability, per-
formance, and long-term maintainability, we recommend that spreadsheets and code be
segregated and prevented from becoming a production system in all but the most immedi-
ate of circumstances. Product teams must resist the temptation (and often management10.2. PROTOTYPING COMPONENTS