Colin Lancaster’s Fed Up

Colin Lancaster’s Fed Up is a new addition to the literature on trading financial markets, promising the inside line on running a macro fund operating in the global markets during the Covid pandemic. Having worked as a sell side techie building trading systems for the last twenty years I’ve read a fair bit of this literature, from classics like Niederhoffer’s Education of a Speculator and Kindelberger’s Mania, Panics & Financial Crashes, to riotous shock fests like Belfort’s Wolf of Wall Street and Anderson’s Cityboy: Beer and Loathing in the Square Mile. For me the real standouts manage to combine market history, financial mechanics exegesis, storytelling and amusing anecdotage. The best example is Michael Lewis’ Liars Poker. Partnoy’s FIASCO and Das’ Traders, Guns and Money are commendable as well. So how does Lancaster’s effort stack up against the canon?

Lancaster plays it slightly differently as he presents a thinly novelized account of his experiences, rather than memoir or narratized tutorial. Because he presents his account as a novel I will mark him down on a couple of points later, but firstly I must recognize his major achievement with this book. Lancaster succeeds in his dramatic reconstruction of the flow of political and economic events week by week since Q1 2020. The lightening quick market reversals, central bank interventions, major political developments, and their impact on a fund manager and his team are described with gripping momentum, and rendered in such convincing detail that I could almost see the teeth grinding desk thumping traders hunched over their Bloombergs.

A novelized treatment gives Lancaster the scope to wander, so along the way we take in a lot of enjoyable pop cultural references. Amy Winehouse, Led Zep, the Stones, Guns’n’Roses, U2 and Freddie Mercury all get mentions. Even Dr John, and that’s one for the real musos! There’s even time for a Hunter S Thompson quote. Fiction also enables Lancaster to lecture his readers on pet economic and political topics. He uses the literary device of mentoring a junior to deliver set pieces on twentieth century fiscal policy, and the dislocation of quantitative easing as the “new normal”. Personally I found mentions of Clinton as the last President to balance the US budget, and the Reinhard-Rogoff paper on government debt to GDP ratios gratifying. Especially as the latter was used by Cameron and Osborne to justify austerity.

So where does Fed Up fall down? If you come looking for detailed explanation of the kind presented in Zuckerman’s Greatest Trade, you’ll be disappointed. If you don’t know what yield curve inversion is, Lancaster’s not going to enlighten you. The presentation of the story as fiction causes some irritation: there’s an Amy Winehouse dream sequence that serves no apparent purpose. And the relationship of the principal with his wife is referenced intermittently, with hints that his neglect has induced her to have an affair, but then it’s all left unresolved. There’s also a slightly sanctimonious tone taken on drug using colleagues that makes me suspect the author doth protest too much. And finally a couple of minor typos and factual errors: there’s no company called HIS Markit – it’s “IHS Markit”, and Lancaster is wrong about the timing of the death of Brian Jones. If he’s as big a music fan as he seems he should have got that one right. But I do appreciate his story about a team outing to the hotel bar where the Stones launched Beggars Banquet back in 68. That was new to me!

In conclusion, I think I’ll rate this as 3/5. Don’t pick this one up if you haven’t read Liars Poker. But if you are familiar with the classics you’ll find it thought provoking, entertaining and enjoyable.

Showstopper!

I’ve just finished reading Zachary’s Showstopper, a riveting account of the development of Windows NT at Microsoft in the late 80s and early 90s. I do love industry war stories, so I’m puzzled by the fact I missed this book somehow. Other similar works I’ve enjoyed include Ferguson’s No Prisoners, Kidder’s Soul of a New Machine and Levy’s Hackers. The book is slightly marred at times by clunky explanations of core development activities like coding, test, debugging and building. Zachary is a tech journo, but obviously not a coder. Beyond that minor objection there’s much to enjoy, and several surprises. Those who’ve been around the software world for the last couple of decades will recognize the dramatis personae: Bill Gates, Steve Ballmer, Nathan Myrhvold, and the NT lead, Dave Cutler, developer of VMS at DEC. The narrative follows an arc familiar to any who have worked on a large software project, with all the typical setbacks and pressures. Here are the points that surprised me…

• Cutler joined MS in Oct 88, and NT development was well underway before the decision to make NT the successor to Windows 3. Originally OS/2 had taken that role. But the unexpected success of Windows 3 in 1990, and Microsoft’s strained relationship with IBM changed all that. Before that NT was a traditional multitasking console OS like VMS or Unix.
• Cutler had three prime design directives: reliability, personality and portability. Reliability was achieved with a properly partitioned kernel mode, unlike DOS & Windows. Personality was accomplished by presenting a different user mode API (Win32) to apps, and keeping the kernel API private. Which much later in WinNT’s history would enable WSL version 1. Personality also enabled Windows 3 apps to run under NT. Portability meant minimizing assembly coding.
• Cutler original target CPU was Intel’s RISC offering, the i860. A CPU so new and buggy that Cutler brought his hardware buddy Roy Short over from DEC to build i860 based systems at MS. Gates wanted to target 80386 first, but deferred to Cutler on many key decisions. Later support for MIPS and DEC Alpha would be added. I remember seeing Alpha based NT workstations in the mid 90s and being very impressed by the power and speed.
• Manual builds! There was no CI/CD automation back then. The guys running the “Build Lab” selected the patches they would take, merged, and built. And the build took 19 hours.
• Most of NT was coded in C, but much of the graphics was in C++. The graphics coders were long time Microsofties, not Cutler cronies from DEC, and they had Gates support in C++. Since Windows graphics only entered the NT picture in 1990, and Cutler was not a GUI guy, they didn’t have to follow his language choice. I remember early C++ compilers – Glockenspiel CommonView anyone? Coding part of a new OS in C++ in 1990 was a very bold choice.
• 20% of the NT team were first jobbers!

Will we ever see a big new OS dev project again? Maybe not. Cutler’s Personality idea enabled the pivot to Windows by NT, but now we have virtualization and cheap hardware, so the Personality job is done by hypervisors. Just look at WSL2 compared to WSL1! OSes have become commoditized, and since Linux is open source, it enables a style of innovation that proprietary OSes can’t match. So, in conclusion, Showstopper is a strong recommend from me, and a nostalgic read for this veteran dev. Almost a “when dinosaurs roamed the earth” experience. And Cutler may have been difficult to work with, but he obviously had massive coding chops.

VoltDB async Python client

I posted a hacked voltdbclient on github showing how it can be made to play nicely with async frameworks like Tornado…

Develop Excel: London 2018-10-18

SpreadServe will be at the Develop Excel conference in London on 18th October. If you build spreadsheets for the trading floor with XLLs you should be there too. I’m especially excited about the session with Govert, Mr Excel-DNA.

Tornado add_callback considered harmful

I ran into an interesting Tornado event loop gotcha last week, so I thought I’d blog the issue. At work I’m building a suite of Tornado Python based microservices to implement an FX options booking stack. The message transports in play for comms with other systems are IBM MQ series and AMPS for pubsub messaging. Naturally we use pymqi, which is a thin Python layer on top of MQ series traditional blocking
C API. Blocking APIs don’t play well with the Tornado event loop. In classic single threaded async style Tornado callbacks should complete quickly and not hog the thread, so that new incoming socket events can be seviced. So the MQ PUTs and GETs were in another thread, which used ioloop.add_callback( ) to
send work back to the main thread. For high volume queues, that means a lot of add_callback( ) invocations. And that’s the gotcha: Tornado’s main event loop dispatches pending timeouts and callbacks before looking for new socket events and dispatching to their handlers. If you have a lot of expensive pending callbacks then your code may be slow to fall through to servicing new socket events. And if those socket events are HTTP GET /health hits from your Marathon platform, then
Marathon will conclude your process is dead and bounce it. Exactly what you don’t want when there’s high traffic! In this case the fix was to make the MQ thread more selective about which incoming messages got pitched over to the other thread with add_callback( ).

Windows EOL

Could Windows die as an enterprise OS? Could it disappear in the same way as desktop  workstations from Sun, SGI & Next? Could it vanish from the datacentre just like Solaris?

Twenty years ago Open Source advocates pushed the Linux desktop as a means to break Microsoft’s stranglehold on PC computing. At the same time Sun promoted Java applets as desktop OS agnostic. In reality it was the iPhone launch in 2007, and the rise of the smart phone that broke Microsoft’s dominance in the consumer space; Android & iOS are the leading phone and tablet OSes and have driven the shift from Windows being the primary GUI to HTML5. But despite the primacy of the HTML5 GUI for new systems, Windows position on the corporate desktop still seems secure. Why?

There are good reasons Windows persists in the business environment when it has receded in the consumer space: corporate knowledge workers need desktop computing, and Windows is still the best option: cheaper than MacOS, easier to use than Linux and more compatible with legacy apps than either. It’s still the best platform for running MS Office, naturally. But maybe ReactOS – an Open Source Windows clone, could eventually change that. With no license fee that makes it cheaper than Windows, so the question becomes: could ReactOS form the basis for a RedHat style play that would eliminate desktop Windows in the same way RedHat Enterprise Linux finished off Solaris? For that to be happen possible ReactOS would need to achieve higher levels of compatibility. Currently it can run a lot of apps including Excel Viewer, but not Office itself. That could be addressed by industry consortia. How much do large enterprises spend on Windows licensing? Potentially, that cost could be taken out in favour of funding consortium efforts to raise ReactOS compatibility, package it for corporates and supply support.

It’s an intruiging prospect, but there are good reasons why it would be hard to execute. Firstly, the sheer technical difficulty of troubleshooting without source code access for MS Office, .Net and other legacy apps. Debugging is a hell of a lot easier with source code access. Secondly, Microsoft’s competitive response; they could drop the cost of Windows volume licensing to zero or near zero. And they could engineer Office and .Net for ReactOS incompatibility. However, both responses could invoke resistance from anti monopoly regulators.

The return of the fat client

Last night I got a demo of a brilliantly innovative IR derivatives system from the founder team. It prompted some thoughts on the cyclical nature of the software industry, and the return of the fat client. Back in the 90s, when Microsoft still ruled the world, client server computing and the fat client were the dominant model for application development. Often the server tier was simply a DB,  and all app logic happened in a Windows app built in MFC C++ or VB. The rise of Java and the browser threatened that model, and met with a forceful response from Microsoft. That’s a well-worn story, and I won’t repeat it here. Java never delivered on its promise of zero deploy desktop OS agnostic apps; anyone remember Marimba? Instead the browser began its long march toward becoming the dominant desktop client. After the dot com bust it took time for web 2.0 to emerge. For a while there was a debate about Silverlight vs Flex vs Ajax. Thankfully Ajax – the only one not aligned with a major vendor – won out, despite myriad incompatibilities between browsers and unsatisfactory server push mechanisms. Websockets and HTML5 resolved those issues, setting the scene for thin client zero deploy nirvana. Or so it seemed.

Concurrently with these technical developments on the desktop we’ve seen the rise of SaaS. The advance of the browser as client enabled ISVs, starting with SalesForce, to bypass corporate IT departments and server rooms, and deliver apps direct to users, often with UI quality approaching consumer products, and very low entry prices. Now there’s no end of CRM, budgeting and financial management, project management and industry specific vertical solutions delivered direct from cloud hosting to user desktops. Each browser delivered SaaS may be cheap and compelling, but they exclude the possibility of integration and data sharing across apps. Unless the business users buying those SaaS apps gets their IT department involved again to build integrations across the SaaS REST APIs. But that ain’t gonna happen, because the users bought into the SaaS apps to free themselves from the dysfunctional IT depts in the first place, and because of that the IT depts hate the SaaS apps in the same way they hate Excel.

So how does the integration problem get solved? On the desktop of course! We’re now seeing the re-emergence of 90s style app to app interop on the desktop. This time the enabler is not Microsoft’s OLE (Object Linking and Embedding), but proprietary extensions to the HTML5 container. OpenFin’s Chromium based HTML5 container supports drag and drop between apps, and also provides a pubsub bus. DDE anybody? This trend is writ large with the startup’s IRD options pricing solution, which addresses the financial sector’s rates options trading niche in a fiendishly clever manner. Anyone who’s ever stepped on a trading floor knows about the ubiquity of the Bloomberg terminal. Bloomberg’s terminal comes with desktop interop; their Excel addin enables live ticking market data in spreadsheets. APIs do the same for desktop apps, but license terms mean that data can only be used by apps running on the same desktop. That precludes publishing Bloomberg market data to the server side pricing systems typical in the bigger hedge funds and banks. So this startup’s master stroke is to deliver IRD options pricing in a browser client, as an SaaS, and driven by Bloomberg market data. The analytics – the number crunching special source – are coded in JavaScript and run in the browser. Truly a browser based fat client offering a unique solution enabled by desktop integration.

We’re going to see more and more of this kind of SaaS delivered HTML5 fat client adding value with smart desktop integrations. Proprietary extensions like those in OpenFin, or the startup’s Bloomberg integration, will multiply. Proprietary extensions will inevitably clash, and the benefits of zero touch deployment to a standardised HTML5 browser client will be dissipated. It’s all yet another instance of the endlessly repeating cycle in our industry: standards consolidate, and competition differentiates. Standards are introduced to ameliorate the pain of incompatibility, then vendors differentiate with proprietary extensions until the level of incompatibility becomes too painful and the cycle repeats. Intelligent market participants should think hard about where we are in the cycle, and how to get ahead of it. But not too far ahead of course!

TFWebSock: TransFICC web socket server

I’ve just updated my Netty based TransFICC web socket server to work with version 330cb31-3670 of the TransFICC API and service. TFWebSock enables web socket clients to subscribe to TransFICC sourced market data. Those web socket clients could of course be browsers, but in the case of this demo the client is the SSAddin Excel addin. Which means that you can use TFWebSock and SSAddin to pull live ticking ICAP iSwap swap rates into Excel on your desktop. And if you want to automate and serverize that spreadsheet you can do so with SpreadServe.

I should point out that the ticking rates in this demo are from the iSwap test system, and are not live production rates. Many thanks to the teams at TransFICC and ICAP for making this data available!

SpreadServe and TransFICC

Earlier in the summer I did a POC integration of SpreadServe with TransFICC. For those unfamiliar, TransFICC has an ex-LMAX founding team, and is a new entrant in the ECN gateway space. Technically their key differentiators are cloud hosting and high performance engineering techniques. For Transficc clients the only thing running on premises is the Java API, which puts the same orthogonalised interface on all the usual fixed income ECNs, and connects to the cloud hosted gateway processes.

It’s been a while since I built anything non trivial in Java, so I was pleasantly surprised by how improved the Java ecosystem has become. Gradle has transformed dependency and package management. And the single threaded async approach popular in the Python and C++ worlds has finally made it to Java with Netty. You can find the code on GitHub here.

 

Automated Baremetrics Spreadsheet

Back in April I read a great post by Jaakko Piipponen on the SaaS financial model he’d built as an Excel spreadsheet. I’m interested in spreadsheet financial models, so I enjoyed Jaakko’s run down on how his model covers PnL report, operating expenses, payroll and revenue. Jaakko describes how you only need to spend 30 mins a month downloading reports from the Baremetrics dashboard and pasting it into Excel to keep it up to date. The post is titled an “SaaS financial model you’ll actually update”, because the value of the model is such that 30 mins of manual handle turning a month is more than justified. Now I’m the first to advocate Excel for business agility; it’s a great tool that enables sales, marketing and finance people to solve problems for themselves without the bottleneck of a software development team. But the downside of Excel is manual operation like the download and paste Jaakko spells out. Wouldn’t it be great if the Baremetrics data in the spreadsheet downloaded and updated automatically? Then the model would always be up to date, and no tedious and error prone download’n’paste operations are necessary.

So I built it by adding Baremetrics functions to my open source XLL Excel Addin SSAddin. Here’s a spreadsheet that strips Jaako’s model down to just the revenue parts of the model…

https://github.com/SpreadServe/SSAddin/blob/master/xls/flight_bare_model2.xls

It uses SSAddin functions to automatically download the revenue numbers every 10 minutes into the MRR Export sheet via the Show Summary API so the Revenue Model sheet will update every 10 minutes with the latest new customers, subscriptions, cancellations, upgrades and downgrades. All you need to do is download SSAddin 32 or 64 bit .xll binaries from here…

http://spreadserve.com/s3/downloads.html

Then install the addin in Excel and fire up the spreadsheet. Don’t forget to ensure that auto calc is on, and that you’ve got a copy of SSAddin.xll.config from the download page and put it next to SSAddin.xll on your PC. You’ll need to edit the .config to add your Baremetrics license key.

You can see flight_bare_model2.xls running online and driven by spreadserve.com data here…

http://sscalc0.online/flight_bare_model2.xls/0

http://sscalc0.online/flight_bare_model2.xls/MRR%20Export

This online spreadsheet takes automation to the ultimate level. When you run a spreadsheet model automated with SSAddin on your desktop or laptop you still have to start Excel, load the spreadsheet and hit F9 before auto updates can start. With SpreadServe hosting, you can move the spreadsheet onto a cloud server. All manual operations are eliminated, and everyone sees the same auto updating numbers in their browsers.