110 CHAPTER ◆ 1 0 Prototype in Modeling Software
pressure) to add more implementation capabilities to prototypes. The team cannot suc-
cessfully turn the intentional low quality of a prototype into the maintainable robustness
that a production system demands. Prototyping facilitates rapid iteration and iteration is
the key success factor in testing and evaluating new trading ideas, but in the end proto-
types should be discarded.10.2.3. Evolutionary Prototypes
Evolutionary prototyping is a development approach in which the product team proto-
types selected parts of a system first, and then evolves the rest of the system from those
parts. Unlike throwaway prototyping, in evolutionary prototyping, the team does not dis-
card the prototype code; rather they evolve the code into the production application that
they will ultimately use in the implementation, that is, the prototype evolves into the pro-
duction software. Evolutionary prototypes provide a solid foundation for building a trad-
ing system ’ s software tools incrementally as the requirements through iteration become
clearer. These prototypes must be built with production-quality code from the outset
and must incorporate good architecture and solid design principles. There ’ s no room for
shortcuts in evolutionary prototypes.
Evolutionary prototyping supports rapid development by addressing risks early. The
product team starts development of the riskiest areas first. If obstacles prove too difficult,
the team can cancel the project without having spent any more seed capital or time than
necessary. Because of the risks, initial planning should identify the biggest obstacles. The
first loop of an evolutionary prototype is generally a pilot release that implements what-
ever requirements are well understood and stable. Lessons learned from user testing and
performance evaluation of the prototype as well as new research into quantitative meth-
ods will lead to modification in the following loop. The working system, in the end, is the
end product of a series of evolutionary prototypes. These work well for trading systems
that grow with each iteration and gradually integrate various data sources and external
systems.^8
Sometimes, S-Plus, SAS, MATLAB, and even Excel and Resolver prototypes may
not be thrown away. Over the last decade, there has been tremendous growth in the
number and types of software applications appropriate for modeling financial instruments
and trading strategies. Some of these applications compile production code (in .dlls)
from prototypes built in the software itself. (For example, MathWorks offers a unique
set of tools that lets you convert MATLAB code into C or .NET code automatically.
Ultimately, MATLAB lets you develop prototypes and convert them into usable software
more quickly.) This trend is sure to continue. These new tools enable evolutionary pro-
totyping although the performance in production may yet fall short. While we generally
prefer throwaway prototyping, we recognize that evolutionary prototyping may very well
be the future.
Evolutionary prototyping may, however, create unfulfillable expectations about the
overall trading system development schedule. When end users, seed capital providers,
managers, or marketers see rapid progress on a prototype, they sometimes make unreal-
istic assumptions about how quickly the team will finish. Additionally, with evolutionary
prototyping, the team cannot know at the outset of the project how many loops it will
take to create an acceptable product. The team cannot know how long each iteration will
last. For this reason, we strongly recommend a minimum of three loops, and a maximum
of five, followed by a gate meeting. If the project is spiraling out of control due to fuzzy
specifications, management can kill the project or reconstitute the product team.