179
communication, and feedback. According to the Agile Manifesto ( http://www.agilealliance.
com ), an agile team:● Focuses on customer satisfaction.
● Self-organizes.
● Communicates face to face, often in daily meetings.
● Focuses on iterative and evolutionary development.
● Strives for technical excellence and simplicity.A development team typically consists of a lead software designer (again, the product
team’s lead programmer/IT professional), software engineers, network engineers, and test
engineers, who perform unit test-driven coding, hardware, and software integration test-
ing, and refactoring in an iterative, incremental, timeboxed manner.
The typical responsibilities of the software engineers are to understand and evaluate the
requirements specifications and alternative architectures, build and unit test the system, and
create design documentation. Where possible the software engineers reuse software compo-
nents from the firm ’ s library of proprietary components. Furthermore, they will purchase,
configure, and extend COTS components where appropriate. Management should not be
allowed to select the programming language. This should be set at the firm level and fol-
lowed by all teams. (While the firm may enact changes on the recommendation of program-
mers, nevertheless development must take place within management-approved technologies.)
To ensure maintainability, management should also lock the framework for coding firmwide.
A development team develops software iteratively. As always, we believe in client-
driven and risk-driven iterative technology development, where the elements with the
highest business priority and risk are chosen first. Each iteration in Stage 3 covers design,
programming, testing, integration, and delivery of a useful piece of software. We prefer
shorter iterations where timeboxes are no longer than two weeks. This process is very
similar to a prototype in K | V Stage 1 except that an iteration in this stage produces a
working portion of the final trading/investment system.
Iterative development dramatically increases feedback versus sequential development,
providing closer communication between the product team and the development team.
Small portions, or batches, beget short feedback loops that enhance control. Shorter itera-
tions, furthermore, force an option-based approach to development, allowing the technology
to respond to proven and tested facts rather than estimates and forecasts. An option-based
approach reduces risk by keeping options open rather than freezing the technology design.
Unit testing and integration test engineers should be involved from the first iteration so that
design problems will be exposed early on. Iterative development and testing forces points of
communication, better use of time and resources, and, in the end, better quality.The development team should consider the documents and prototypes from Stages 1 and 2 to be the base
code used for testing. Programmers sometimes ignore specifications and designs, preferring to just start cod-
ing. This leads to design errors, including nonscalability, and produces poor design documentation. Instead
of being encouraged that the software is finally being built, the product team will become discouraged.
Without firm design documents in line with the initial requirements specifications, a completed system should
not pass a due diligence process, be funded by investors, or allow the sale of the system and its fund.
Developers must follow plans. A construction team building a bridge would be fired immediately for
changing designs away from the prototype structure. A development team programming flight controls
would be fired immediately for not building to the prototype and simply coding on the fly. Top manage-
ment must be firm on this concept or give up on our methodology. Deviation at this point will result in
out-of-control development and failed projects.
19.1. D EVELOPMENT TEAM