Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An oral history of Bank Python

calpaterson.com

Post reply on HN
Print view View original

41–50 of 333 posts

Re: An oral history of Bank Python

#41

Post by simonh »

rich_sasha wrote: post #24
lmm wrote: post #19

I'm seeing a lot of people speculating about which bank this might be; I think the point is that it's all of them. I could loosely describe a previous job as implementing Morgan Stanley's Walpole and integrating more source code management into Minerva (even though that system wasn't actually Python-based). Having a global view on everything is large banks' value-add, it's why they haven't been outcompeted by their m…

I think it’s mostly true. The complaint with this kind of “industrial global Python code base”, be it at banks or elsewhere, is that often they are hastily cobbled together and depend on extreme user care to not flop over all the time. I guess banks are the archetypal places that care only about feature creation and not about maintenance or technical debt. When something does break in the end, someone senior just sho…

You could not be more wrong. Quartz has first class documentation, solid tooling, very well thought out and rigorous code review and access controls. Banks are regulated up to the eyeballs, so everything has to be audited and justified in detail.

It's not nirvana, these are real working systems built by humans with human failings. There are tradeoffs. Not every application is suited to these sorts of platforms, but the people building these things are top notch technologists and know what they're doing.

Re: An oral history of Bank Python

#42

Post by zwaps »

I can report from another bank (in the top 10 globally), that recently moved from a more bespoke system (not even on Python) to having Python+Notebooks+Labs available to all - using Apache products and a global Anaconda-like Python distribution. The fact that you can use the Python, R or whatever programming language seems to be a factor.

Re: An oral history of Bank Python

#43

Post by oxfordmale »

I worked for a hedge fund that build their own database on top of MongoDB. Data was serialised and stored as binary blobs. This bonkers implementation took away any advantage of using MongoDB. Unfortunately this system had a lot of political backing, and rather than addressing the short comings we were told to simply datasets to ensure they could be stored in this bespoke database. I suspect a lot of trading signals were lost this way.

Re: An oral history of Bank Python

#44

Post by harel »

I worked on Quartz for a while as a contractor. Hated every second of it. Python version was old (2.4 if I remember correctly when 3.x was already the popular version). But that wasn't it. It was the proprietary version of everything in the stack that got me. Proprietary ide, source control, libs etc. I noted that none of the others who have been there for years have any transferable skills that can cary them out of banking and into a startup for example. All were good devs but only knew quartz. I can say they were great quartz devs. The pay was great, but the work was soul crushing.

Re: An oral history of Bank Python

#46

Post by rich_sasha »

simonh wrote: post #41
rich_sasha wrote: post #24

Earlier quoted context omitted.

I think it’s mostly true. The complaint with this kind of “industrial global Python code base”, be it at banks or elsewhere, is that often they are hastily cobbled together and depend on extreme user care to not flop over all the time. I guess banks are the archetypal places that care only about feature creation and not about maintenance or technical debt. When something does break in the end, someone senior just sho…

You could not be more wrong. Quartz has first class documentation, solid tooling, very well thought out and rigorous code review and access controls. Banks are regulated up to the eyeballs, so everything has to be audited and justified in detail. It's not nirvana, these are real working systems built by humans with human failings. There are tradeoffs. Not every application is suited to these sorts of platforms, but t…

Well, I don’t know about Quartz. I worked with DB systems and they were awful in that regard. They worked, but largely because people stuck to convention.

For example, changing scheduler jobs required submitting a change in Excel and having it approved (twice...) by someone. Except the table was world-writable and changes not logged. So in principle only your appropriate superior could approve change, in practice anyone could, and you’d never even know.

Re: An oral history of Bank Python

#47

Post by p_l »

blitzar wrote: post #27
jeffrallen wrote: post #17

Earlier quoted context omitted.

Everything is fine, as long as no Americans come and write 1,000 where obviously they should have written 1000 or 1'000. /s

Or some american writes the date somewhere. edit: /s we love you american colleagues,

I can confirm that, in a non-bank financial institution, date formats involved with Excel->CSV->XML->Certain (shit) magic application were considerable pain point :|

Re: An oral history of Bank Python

#48

Post by simonh »

blitzar wrote: post #27
jeffrallen wrote: post #17

Earlier quoted context omitted.

Everything is fine, as long as no Americans come and write 1,000 where obviously they should have written 1000 or 1'000. /s

Or some american writes the date somewhere. edit: /s we love you american colleagues,

Working with and for Americans is why I always use ISO year-month-day format.

Re: An oral history of Bank Python

#49

Post by globular-toast »

eb0la wrote: post #39
dash2 wrote: post #32

> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap. This rang a bell. How did deployment become such an arcane skill?

There are too many factors here. One of them is you don't own where your code runs anymore. This might scare some people until they realize they can get high availability without waiting 3 months for some server to arrive, but it makes deployment harder. I still believe the main reason people adopt CI/CD today is that "suddenly" deployment in a complex environment becomes easy and software gets tested. A lot.

> One of them is you don't own where your code runs anymore.

That's not new. The first money I earnt from computers was making websites. We didn't own the webservers; we rented webspace from some company. To deploy it, we literally just uploaded PHP files to a place using an FTP client. It was that simple and it worked.

Re: An oral history of Bank Python

#50

Post by p_l »

nraynaud wrote: post #13

it has a bit of a smalltalk flavor, where the runtime is a memory image, with objects and data in a giant jumble.

There's one smalltalk vendor whose main product is an object-oriented database that is also a smalltalk instance (and you use other smalltalks as IDEs to it).

GemStone/S

Post reply on HN