209
22.3.1. Code Reviews
During code reviews, development team members systematically review coded units.
(Some firms choose to use pair programming as an alternative to individual coding with
reviews.) There are even tools to automate parts of the review process. Some development
teams, though, skimp on code reviews and walkthroughs. Just like in K|V 1.4, a decision
to ignore review techniques that are proven to find defects is tantamount to a conscious
decision to postpone corrections until later, when they will be more expensive and time-
consuming to fix. While formal code reviews can be time-consuming, more informal
review processes, such as pair programming, still yield excellent results. Whatever the
case, preventing or detecting and removing defects early in this step yields significant
schedule benefits. We recommend developing a lightweight code review process and
integrating it into development. Formal software reviews should be conducted at the
completion of each software layer to identify problems.22.4. LOOP 1: Program Business Rules Packages
In Loop 1, the development team programs the business layer according to the designs of
the previous step. As we have said, the product team may have already converted some
of the trading/investment algorithms prototyped in Stage 1 into code over the course of
Stage 2. This code can be used in the production system. Where this has occurred, the
development team should not need to spend extra time reprogramming and retesting these
features; regression testing should have already ensured correctness. Furthermore, the
product team should have fully documented the architecture of these components.
Where the development team does need to convert a prototype from one implementa-
tion, say in Excel, to code over this stage, the development team must perform regression
testing against Stage 1 results to ensure that errors are detected and fixed. Conversion often
creates problems. Hopefully, experienced product team members will have designed pro-
totypes in such a way so as to ease the conversion process. In the worst case, conversion
becomes a reverse engineering project by programmers who may or may not understand
the underlying finance theory or trading/investment strategy. A common programming
error at this point is changing data cleaning algorithms. A programmer may try to enhance
these algorithms, failing to understand that a revision of input data requires a new backtest,
a reversion to Stage 2. A complete regression test of the Stage 2 cleaning algorithms
against the real-time implementations is critical. The development team should also dis-
cuss shutdown criteria due to bad, or too much, data with the product team to ensure that
these algorithms do not affect the performance characteristics from the backtest.
White box, gray box, and black box unit testing, also performed by software engi-
neers, will validate the smallest testable parts of their code. (In object-oriented program-
ming, the smallest unit is the class.) For correct unit testing, each test case must be inde-
pendent from other cases. Traditionally, a unit test should never go beyond a class. But,
unit testing on classes alone is not sufficient. Just because the objects and methods are
working correctly, does not necessarily mean that they work together to correctly form
working modules. For our purposes, the term unit testing consists of testing each class,
as well as related objects that comprise modules. (This approach will evolve into what is
called bottom-up integration testing in Loop 2.) Unit tests may be either performed man-
ually or in an automated fashion. Manual unit testing should follow approved unit testing
policies and procedures. The team should keep records and results of the tests.22.4. LOOP 1: PROGRAM BUSINESS RULES PACKAGES