An interview with Jamie Allsop

In spite of its central role in banking, many financial employers see IT as a “necessary evil”, says former NYSE programmer and clearpool.io director Dr. Jamie Allsop.

JAXenter: Can you tell us a bit about what has changed for programmers in finance since the financial crisis?

Jamie Allsop: I think the biggest change since the financial crisis is probably that programmers are much more aware of the regulations governing the areas in which they work. It is also probably fair to say that development best practices are getting more recognition than they used to in the FinTech space. When failing is rare, old habits die hard, and change is seen as a bad thing.

With increased regulatory scrutiny and the pressures that come with it, businesses have been forced to have a closer relationship with their development organisations. In some cases at least this has had the positive effect of making them more willing to seek advice from, and listen to, development. As an example, when the SEC introduced their preliminary circuit breaker rules in the US we found ourselves directly involved in helping the business understand the implications. The classic business analyst model was effectively bypassed.

Of course in many business domains this sort of direct relationship is a hallmark for success, but the FinTech space has been slow on the uptake.

Would you call yourself a FinTech developer?

I can’t say I’ve ever referred to myself as a FinTech developer, though I am sure I could be described as one. I think, like many people who made a career in the development space, you let your experiences and skills speak for themselves. There are many areas of overlap between the FinTech space and other industries. Often people from outside finance can bring in different sets of values and perspectives which can only benefit the industry as a whole.

I started off in the DSP space and I don’t think that was a detriment to me. Equally I know quite a few excellent people who have come in from other industries. Cross-pollination of talent is what helps keep software development fresh.

Do you ever have trouble innovating in the financial space?

Yes, all the time. Again I think this is a throwback to the fact that many financial companies see their development units as a necessary evil more than a primary producer of actual business value. In this day and age almost all financial companies rely heavily on their technology to function but still treat that function as having second-class importance to the business as a whole. That many of these companies are financially comfortable allows them to paper over failings in how they utilise their development capacity.

“Many financial companies see their

development units as a necessary evil”

When I first moved into the financial space I was shocked at the variance in quality – mainly because failure wasn’t something people were used to experiencing. That variability was both in development itself and the business interfaces and attitudes to it. Innovating in an environment where good, bad or ugly gets by is hard, because there is no catalyst for change. Fortunately though bad and ugly do sometimes lead to a big enough failure that creates a space for trying new things.

SEE ALSO: Innovation in banking – “If it’s new, then it must be risky”

One memorable case I experienced was the classic 6 week project that was 6 months late. I’m sure many have similar stories. Sometimes projects like that still muddle on to eventual release – notice I did not say completion, or success! Fortunately though regulatory compliance can be the saving catalyst needed to cause a serious re-think and willingness to try something new. Interestingly it is also the reason that sometimes prevents innovation, as anything new is often considered high risk and to be avoided. Regulatory compliance really is a double-edged sword for innovation in finance.

How does one end up programming for finance enterprises? Is it your range of skills that got you there, or a clear interest in that area?

In my case it was my compatible set of skills that brought me into finance. I certainly had a curiosity about the space which led me to pursue work in the area, but from the outside looking in, finance was about as exciting as enterprise software to me – which I have also worked in.

But what you never see from the outside are the wonderful technical challenges and the fascinating intricacies of the domain. Most domains have their own set of problems that are a great experience to work on. Especially if you can achieve a good level of exposure and the finance space is no different in that regard.

Is it ever difficult being a C++ and Python expert programming in the Java-dominated world of finance?

Now that was not a question I was expecting! The short answer is, no, because in the little part of the world of finance where I work it seems that C++ is the language of choice.

“My expertise in C++ helped

bring me into the finance world”

The long answer is I’ve been actively involved in C++ since I first started programming and it has been my primary development language throughout my career. In fact it was exactly my expertise in C++ that helped bring me into the finance world, where, as I’ve said, it appears to dominate in the part where I operate. I typically work on large or high performance systems and, as it turns out, many such systems rely on the performance that can be achieved through a language like C++.

JAX Finance is a conference dedicated to Technology in Finance. The two-day event will take place at the heart of the international finance industry in the City of London on 28 and 29 April, 2015. A must-attend for everyone working in finance tech, the JAX Finance will help developers and technical stakeholders build better software and innovative business systems in their industry.

We are currently building an ultra low latency exchange platform and C++ is a perfect fit. That’s not to say other choices may not be as good a fit, but it works well for us. As a language though C++ suffers from a level of complexity that leads to a great deal of variation in the quality of its practitioners but in the right hands it is possible to build simple and elegant systems that offer a performance level not easily achieved by other approaches. With C++11 and C++14 things are only getting better.

As might be expected relying solely on the use of a compiled language is limiting and that’s why we typically reach to Python as our scripting language of choice. Python though is more than that as we use it to perform our builds (through our own tools built on Scons) and also for prototyping, testing, deployment automation, in fact, lots of things. What’s nice about that is that there is no secret sauce for any part of the work we do, most developers can reach a high degree of comfort and familiarity with both the system itself as well as the ecosystem surrounding it.

What would you say are the main differences between programming for finance tech and other enterprise technologies?

If anything I’d say the regulatory constraints within which you need to operate. In that too there is great variation. Some software for example isn’t really impacted at all by compliance issues but others, like exchange platforms are heavily influenced. What this means is that you typically are developing for two main customers. The actual users of the system itself, and the regulatory body that overseas the critical aspects of its operation.

SEE ALSO: Banks “pay 33% to 50% more” in developer salaries

It can be hard making sure you satisfy a customer at the best of times but it becomes completely unforgiving if not satisfying a customer results in legal and financial penalties. Of course that also makes the work interesting. Problems often have an extra dimension to them that can really make it rewarding when you find a good solution.

You claim that poorly optimised but well-chosen architecture will vastly outperform a highly optimised but poorly-chosen architecture. How is this?

When I first moved into the finance space I was fascinated by the countless hours that went into attempting to profile binaries and then even more hours spent optimising various implementations of some perceived-to-be bottleneck in the code. As you might imagine these were in large complex systems. Now there is nothing wrong with trying to figure out how your program is running, but, like debugging, good architecture, design, quality coding and testing should decrease the hours needed for the activity.

In fact I recall I was once proudly directed to a hand-written conversion routine to convert numbers to strings that apparently was marginally quicker than the standard library provided version. And, since it was called millions of times in the code-base, using this version (with its own unique API no less) over the standard version, shaved an almost significant amount of time off overall processing.

As a newcomer to the codebase I was able to look at it with a fresh pair of eyes and soon reached the conclusion that the main problem was not the number to string conversion but the fact that we made the conversion at all. The moral of the story was that had the system, in and of itself, been more expressive about what it did and why, then it would have been easier to choose where best to spend the time in improving it. In this case a different approach allowed the removal of some unnecessary conversion code and that led to much better improvements overall.

“Identifying and implementing architectural intent

will lead to much better performance”

If you take a step back from that simple example and look at architecture as an expression of intent then it becomes clear that being able to better identify and implement that intent will lead to much better performance. This is not a lot different from the choices and trade-offs we take when we choose an algorithm. Choosing a better algorithm to capture your intent and encode your choice of trade-offs is always better than trying to optimise the wrong (or poorly selected) algorithm. In that case you might be choosing between linear and log complexity for example, regardless of how well optimised the underlying implementation is.

If you assume at least a reasonable implementation then the correctly chosen algorithm will outperform even an optimised poorly chosen one. Why? Because the right choice of algorithm is doing what you want it to, within the trade-offs you accept. A good architecture is no different.

You can hear Jamie speak about performant architectures in the evolving regulatory landscape at the JAX Finance conference in London, April 28-29.