178 CHAPTER ◆ 1 9 STAGE 3: Overview
properly transferred. The financial engineers from the product team over the course of
Stage 3 manage software quality assurance of business tier software. The traders from the
product team perform and/or oversee quality assurance over GUI, integration, and report-
ing mechanisms, as well as run user-acceptance tests. The marketing person from the
product team can write or oversee the writing of the user documentation for the software.
Essentially, the product team is the customer of the development team.
The breakdown of these roles is critical to ensuring the project moves forward quickly.
Often we find the financial engineers and traders believe they should be in charge of pro-
duction programming. We recommend this be avoided for the following reasons:● Standard coding is a poor use of financial engineers ’ time. Programmers should pro-
gram. A better use of a financial engineer ’ s time is to work with risk managers to
design risk controls and perform quality assurance testing.
● The skills that make a brilliant financial engineer do not necessarily make a brilliant
programmer. Financial engineers often (and should) spend their programming time
on algorithm development and prototyping, ignoring pure technology issues such
as error handling, GUI design, and data interfaces. (Financial engineers sometimes
consider these tasks to be grunt work.)
● Traders, on the other hand, think only about money and, since bonuses are on the line,
often push for software release at the expense of its stability. Proper error handling
takes time, but is not apparent to end users. Error handling can sometimes become a
“ future feature ” when traders oversee software development. This type of fast track-
ing works well until fatal errors arise. Then, the traders blame the programmers, and
the programmers blame the quality assurance testers. Traders should be responsible
for user acceptance testing, and 100% accountable for errors. The finger pointing will
then be at them. Any monetary loss due to poor user acceptance testing should be
billed directly against the team ’ s bonus. (This is the norm in standard engineering.)We also recommend that the product team now add a risk manager, who will learn the
specifics of the trading/investment system and be able to recommend how best to build
out the risk management functions and reporting requirements. Risk managers must
understand the trading/investment system along with helping structure what risk controls
and reports will be required for Stage 4. The addition of the risk manager is critical for
speed of implementation since the product team may finish a system without well-defined
risk parameters. In such a case, the risk management department may not set trading or
limits until they fully understand the trading/investment system.19.1. Development Team
Stage 3 is where the development team ’ s senior software engineers take control of the
project to design and build clean, optimized, robust, and fast software. Of course, software
development processes have been researched in depth over the last 40 years, and in this
step we will not rewrite the research, but rather link our K | V methodology to agile proc-
esses and the Software Engineering Institute ’ s (SEI) models for designing and building
tight software. We do, however, believe in test-driven development where the development
team iteratively writes test cases first, then writes only the code needed to pass each test.
The technology development team is responsible for the design, coding, testing, and
implementation of the software and network components of a trading/investment system.
We recommend this team follow more agile development principles, embracing change,