December 6, 2014
For the last few months I’ve been working on a new product: SpreadServe. SpreadServe’s mission is to take all those unwieldy spreadsheets full of XLL addins and VBA macros off trader desktops, and turn them into resilient, automated, scalable enterprise services. Excel spreadsheets are great, because they empower users to create their own solutions quickly. But on the other hand, they’re a liability, because they’re usually poorly tested and they have to be manually operated on the desktop. SpreadServe’s goal is to fix that by providing an alternate runtime for Excel spreadsheets. Retain business agility by continuing to design and build models in Excel. Auto-test, deploy, scale, log and automate those models in SpreadServe. Do contact us if you’re interested in joining the beta program.
September 29, 2014
Zac Townsend‘s post on how Standard Treasury aims to turn banks into platforms is intriguing. There’s certainly no lack of ambition in his goal. But I do wonder if he’s setting himself to tilt against the very nature of both banks and platforms. One of the key phrases in Zac’s post is: “allowing developers to think of banks as platforms”. I’ll just unpack that a little. First, platforms, as explicated in Evans & Hagiu’s excellent Invisible Engines. Platforms are multi-sided markets. One side pays for access to the revenue generating customers that an effective platform aggregates by offering free or cheap access. For example, in gaming, game devs pay licenses to platform (console) owners so they can sell to gamers. The console manufactures sell consoles at or even below cost. In financial trading clients pay Bloomberg for access to information & liquidity, and dealers get access to the platform without paying fees to Bloomberg. Famously, Google and Facebook offer services free to consumers to enable them to sell to advertisers. So if banks are going to spend a load of cash adopting Standard Treasury tech so they can become more like real software platforms, who is going to pay?
Let’s bear in mind that banks are already liquidity platforms. They charge fees for access to the liquidity they provide by aggregating client capital. They disguise fees by making some things “free”, and charging for others when they cross sell. If you attempt to commoditise or aggregate by means of a software platform, they lose the cross sell, and so the margins. They will certainly resist that prospect. So, any software platform that integrates banks with with software services needs to offer the prospect of more margin in existing deal flow, or new deal flow to justify the cost of adoption. Judging by Zac’s post, it looks as if he thinks the new deal flow would come from the underbanked via mobile apps. Will that deal flow justify the cost of implementing Standard Treasury tech? I’m sceptical…
Standard Treasury should also be considering the cost of decommissioning those expensive legacy systems. In banking old and new systems tend to run in parallel until all stakeholders are confident that the new systems supports all legacy system functionality. So new tech that promises cost savings tends to cause a cost spike until the old system really has been put to bed. And, believe me, that can be a lengthy and painful process! I have first hand experience of systems that have resisted retirement for decades…
May 5, 2014
Tales flags some interesting developments in the Python world. The demand for Python developers in finance does seem to be building. Both Man and Getco are big users, and as Tales points out, JP Morgan and BAML both use Python as the primary programming languages in their Athena and Quartz systems, both of which are inspired by Goldman’s SecDB/Slang. Tales wonders if Washington Square Tech will the fourth implementation of this paradigm; I believe it may be the fifth, as Morgan Stanley had an Athena like project called Pioneer during Jay Dweck’s ill fated tenure. Apparently that project is now defunct. The Athena paradigm is technically a very powerful solution for trading businesses that have run on ad hoc solutions using Excel for pricing and risk. Partly because they seek to replace Excel based pricing and risk, and partly because it’s compute efficient, all implementations of the Athena SecDB/Slang paradigm implement Directed Acyclic Graphs. I’m guessing that Washington Square Tech will think this could be very appealing for buy side firms that don’t have big in house tech stacks, together with incumbent tech teams defending them against replacements.
Directed Acyclic Graphs (DAGs) are a powerful implementation technique for minimising the load of compute intensive tasks like pricing and risk, and this is one good reason why Excel has been so successful in this area, as Ben Lerner of DataNitro explains persuasively here. So it should be no surprise to see that Man Groups own open source Python codebases include a DAG implementation, MDF. The MDF docs include a very good illustration of the power of the DAG approach.
August 8, 2008
So I caved in recently and got a CrackBerry. It was the evening calls to team members in New York that did it – I didn’t want to make transatlantic calls from my personal mobile so signed up for the corporate electronic handcuffs. I swore to myself that I wouldn’t spend personal time checking and sending emails – it’s important to me that I use my commute time for reading. And guess what, I managed to refrain from compulsive email checking.
But I fell victim to a far more pernicious compulsion: BrickBreaker. BrickBreaker is part of the BlackBerry’s base set of applications, so everyone has it. It’s a variant on Atari’s 1976 classic Breakout. I’ve avoided video games for years, and haven’t really played them since I was a student, since I know I can get fixated. So I haven’t installed them on PCs, and I’ve stayed away from my kids’ Xboxes and PSPs. But BrickBreaker is pernicious because it’s always there – you can play on the train, or in a boring meeting. Since many who carry a CrackBerry are IT management types, they’ll have grown up playing classic Atari games like Space Invaders, Asteroids, Breakout, Pacman. So they’ll be especially vulnerable to a bout of BrickBreaker dependency.
Evidence of chronic BrickBreaker addiction is widespread. Plazmic, the creators of the game, have forums that carry detailed discussion, including the BrickBreaker basics primer – obviously written by a hopeless addict. The Plazmic forums also have Philip Bennett’s Diary of a BrickBreaker, which could be a case study in compulsive behaviour. Over on BlackBerry’s own BrickBreaker forum you can download a PDF detailing the layouts of all the levels, and the locations of the power pills: brickbreaker_v4.2_screenlayouts.pdf.
All addicts eventually have a moment of clarity, when they realise the wastefullness and folly of their habit, and resolve to break it. Mine came at the sandwich bar in our canteen. The lady behind the sandwich bar is used to seeing me with a book as I queue, and asked me why I wasn’t reading. I admitted I was playing BrickBreaker, and that I was hooked. That was the turning point…
February 26, 2008
So what is running on the desktop of a buy side fixed income trader ? From my viewpoint here inside a dealer, I imagine the buy side do all their trades on Bloomberg, TradeWeb or by phone. But then I am an etrading guy, so I would say that, wouldn’t I ?
October 18, 2006
Are there ever sound reasons for deliberately making a user interface unintuitive and inconsistent ? For deliberately making life difficult for the user ? I know I’m drifting off topic here, but the thought crossed my mind as I used our corporate web based expense reporting system to file a claim for a conference I went to earlier this month.
This expenses system is terrible. The help is cryptic, and the workflow seems wilfully obscure. Is it just bad design, or should an expenses system be designed like that to cut down on employee claims ?
At another bank in the late 90s we all used a timesheet system called Agresso. It had an appallingly clunky Windows GUI that violated every possible expectation you might have about the interface – like TAB going to the next field. It was infuriating. Take a look at Agresso‘s stupid raging bull logo. No doubt it’s designed to appeal to alpha male senior managers. Ironically, it perfectly captures the mental state of a user after sustained exposure to its late 90s GUI. I guess that’s what happens when there’s a disconnect between purchasers and users. If we foisted crap like that on our traders, by golly we’d know about it pretty quick. They insist on minimal and intuitive keystrokes and mouse gestures.
October 9, 2006
Looks like Aleksey Vayner is the new Lucy Gao. I strongly recommend you watch the video on YouTube – it’s utterly hilarious.
September 13, 2006
So we’re still in the middle of the recruiting round I alluded to earlier. Joel on Software is one of my regular reads, and I’ve followed his recent posts on recruiting. One post presents an amusingly stereotyped caricature of the relationship between developers and traders, and bank attitudes to technology. Scroll down to the bit about “Use cool new technologies unnecessarily”: I think Joel must have read Liar’s Poker. Needless to say, it’s not really like that…
June 27, 2006
…we were half a million long” [with apologies to] Crosby, Stills and Nash.
Paul Graham has posted a new essay on outsiders vs. insiders – thought provoking stuff as ever. So who are the outsiders in our industry, wholesale finance ? Hedgestock, the hedge fund industry beano reveals the hedge fund self image: they’re the counter culture, the underground.
In recent years there’s been a big flow of capital, traders and techies into hegde funds. The capital is seeking returns, of course. The traders are seeking compensation too, as well as freedom from the corporate culture of the big trading banks. And the techies are fleeing the sometimes stifling technical culture of the big banks, with onerous change management and architectural standards. Naturally, the techies are chasing big bonuses too.
Paul Graham has a very pro start up bias in his writing. Not surprising, as he hit the jackpot big time with Viaweb. I’ve worked for small, large and medium sized companies. My experience suggests that PG over emphasizes the freedom of start up environments. When I’m struggling against the inevitable bureaucracy of a large organisation, small companies can seem like highly liberated environments. But it’s important to remember that in a small company, you have to do a bit of everything: sales, admin, marketing. In a large org, there are people to take care of that, so you can specialize. If you get the right role, you become free to concentrate on the good stuff, to concentrate on what you do well and what you enjoy.
Back in the early 90s I worked for a medium sized ISV in the oil industry. In many ways that was the perfect environment. The company was large enough to support specialisation, but still small enough to avoid bureaucracy and a process centric approach. Still small enough that everyone knew everyone else.
I wonder if that kind of environment exists anywhere in etrading ?
“Organizing for routine work: Drive out variance”
“Organizing for innovative work: Enhance variance”
Back in the early 90s the tension between the 'impose a routine' imperative of structured methods like JSP and Constantine/Yourdon and the necessary creativity and innovation of software problem solving drove me mad with frustration. Object orientation was crossing over into the mainstream, and a new generation of methodologies based on structured methods, but tweaked for OO were propounded by their advocates.
The promise of those methodolgies was to make software development routine and predictable, hence their appeal to managers. Of course, we now know software development isn't routine and predictable, and trying to make it so is like trying to nail a jelly to the wall. Trying to make it so is to organize for routine and to attempt to execute innovation. No wonder it didn't work! More recently, agile approaches have acknowledged the essential nature of dev work, and offer a process that works with, not against, its intrinsic nature.
So back in the early 90s I'd become so maddened by the impose routine/execute innovation dichotomy that I spent a week in the Bodleian Library researching a paper that would decisively reject the claims of the software methodologists. It was to be based on twin foundations: the empirical study of programmers, and Paul Feyerabend's Against Method.
I first came across Feyerabend 20 years ago as an undergrad, browsing the Philosophy shelves in Heffers. I came across a copy of Farewell to Reason, and intrigued by the title, bought it. I'd been studying the Philosophy of Science, and covered the usual ground with Popper, Kuhn, Lakatos, Papineau. But no one had mentioned Feyerabend. Once I read Farewell I realised why. It's packed full of exciting, radical & contrarian ideas – for instance he defends the Church against Galileo !
Much of the Philosophy of Science is about science's purported special status in human intellectual activity as a generator of truth and certainty. As such it attempts to give an account of how and why science can generate knowledge, usually in terms of the scientific method. The logical positivists characterised the scientific method in terms of the principle of verification. When that was shown to be self contradictory, Popper's falsificationist ideas came to the fore. They're all epistemology, being theories about knowledge.
Feyerabend is an epistemological anarchist. Against Method is a sustained polemic against the very idea of a scientific method. It argues that any conceivable scientific method is refuted by examples of actual science. He examines cases from medicine, chemistry and physics and shows that no progress could have been made if scientists had stuck by rigid rules as per Popper.
Against Method is full of delightfully contrarian insights such as "semantic sloppiness is the prerequisite of progress" and "the only principle that does not inhibit progress is anything goes". When I returned to the book in the early 90s, it seemed obviously applicable to software development. Now that Agile is widely accepted, that argument doesn't need to be made.
So when I see people asserting that we need more than innovations, we need a process for innovation, I think "the only principle that does not inhibit progress is anything goes". It's a lesson that's been learnt at great length and expense in software development. And it looks like there are many others who could still benefit from Feyerabend's insights.