I recently led the development of a Fair Value pricing service for an Investment Bank client over a period of 6 months. The bank’s analytics team implemented the pricing logic in Java, which we wrapped and exposed as a managed service, hooking the loan management application and batch processes into it.
During the project, I advised the development of the pricing logic with respect to structure, best-practices, design – just the technical issues really, with analytics concentrating on the hard-core financial engineering. During the project, I came across a really interesting (for me anyway) scenario where the Template Method Pattern could be used.
We noticed that the pricing library developed by the analytics team had slowed considerably. Whereas a few loans could be priced per minute previously (it’s an expensive operation and involves a third-party C++ library which we couldn’t modify), as development progressed the library could only price one loan in 50-70 seconds.
Clearly this concerned us. Investigation using JProfiler revealed that for a single loan, product type methods such as isRevolver() and isGuarantee() were invoked several hundred thousand times. Additionally, the String equals() method was being invoked over 1 million times.
As development progressed, additional financial products were supported by the calculation. Further investigation revealed that as each product had been added, calculation logic that should only be invoked for some products but not for others was enclosed within conditional logic that checked the type of product (e.g. isRevolver()). As further products were supported the code became more and more spaghetti-like.
The pricing library, by definition [model undisclosed], performs a price calculation at multiple points in time throughout the maturity of a product. As such, the pricing logic was executed within a loop.
In addition, the product type methods such as isRevolver() and isGuarantee() compared a private Product member String variable (its type) against a public constant (static final) String using the equals() method.
Recap:
- The calculation is performed within a loop.
- The calculation can be viewed as a sequence of steps – some which should be performed for a given product, some which should not, some which should do different things dependent on the product (i.e. different input values to the calculation).
- As a result the product type is compared many times during the calculation, within a loop (in fact, a loop within a loop).
- The product type comparison uses the String equals method.
I mentioned this to my IT colleagues, as well as my recommendation for the analytics team:
- Introduce the Template Method Pattern to better structure the product-specific logic. In doing so the calculation algorithm is implemented in the abstract base class and product-specific calculations are implemented in the concrete subclasses (or not, if the step should be bypassed). This wouldn’t reduce the product type checking… it would eradicate it. It would remove all spaghetti code, all product type conditional logic, reduce the number of String comparisons massively, and enhance the performance of the library considerably.
- Refactor the product type from a String to an enum, resulting in type safety, removing the need for parameter validation (which was extensive) and improving comparison performance considerably.
My colleagues agreed for the most part, but I was surprised by the comments of one developer. His initial thought was “You shouldn’t use patterns in an analytics library. It’s analytics. Why would you do that?”
This surprised me no end. If there was ever a time to use the Template Method Pattern, I was sure this was it.
Definition (Design Patterns: Elements of Reusable Object-Oriented Software, Gang of Four):
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
The calculation was definitely an algorithm. It had parts that should happen for some products, not for others, or in different ways for each product. The overall algorithm – step-wise – never changed though.
Template Method Pattern In Action
The Template Method Pattern refactoring is still in progress, but will improve the performance of the pricing library and its design massively.
The introduction of enums improved the performance of the calculation by several seconds.
As an aside, I was surprised by the anti-pattern sentiment of my colleague’s comment. I totally agree that “Pattern Fever” is a risk, but I wonder whether some developers are still very sceptical of the benefits patterns afford? I’m perfectly happy if the developer is already structuring their code in the same well-designed manner, just without the fancy label… but I fear that might not be the case.
I wonder how prevalent Gang of Four patterns are in Financial Software development. Sure, Enterprise Design Patterns revolve around architecture, as do (messaging, etc) Integration Patterns, but surely fine-grained patterns can be applied in any sector down in the depths of the business logic, not just in the technical infrastructure. Don’t be shy!
I’m tempted to start a poll on this, to see whether developers in the trenches really do embrace the (now old!) new-age patterns culture. Watch this space…
May 3rd, 2009 → 11:03 pm
[...] Java Processes I previously blogged about a Fair Value pricing service I developed for an investment bank client. Another interesting observation I made during this [...]