Adam Wolf leads the software infrastructure group in Bloomberg's Engineering department. His team is responsible for developing the foundation on which more than 6,500 developers build their applications and roll out new code that integrates instantly into clients' workflows.
He tells ZDNet how the finance and data giant uses a range of software development techniques – from sharing knowledge to creating 'guilds' and onto embracing open source – to meet the needs of its customers in the global financial markets.
Bloomberg's workflows span the gamut of financial services capabilities, from real-time market data and analytics to income, equities, foreign exchange and commodities. "Trying to do all this requires us to be efficient, but also requires us to be lean," says Wolf.
Wolf has spent more than 17 years at Bloomberg, having previously led the organization's communications and mobile teams as well as various technical and leadership roles within its news engineering unit.
He has also led Foundational Applications – the core, cross-asset-class applications and platforms on the Bloomberg Terminal, spanning email and instant messaging services, search and financial big data platforms.
Bloomberg Terminal is an all-in-one computer system that gives financial services professionals access to Bloomberg's financial data, analyst estimates, messaging and trading services. It sits at the core of Bloomberg's product portfolio, and serves more than 325,000 subscribers all over the world.
Twenty or so years ago, Bloomberg Terminal was, quite literally, a computer terminal. It then became a Windows desktop app, whereas today, as Wolf explains, "the Bloomberg Terminal acts as a browser, but it's a custom browser and it has a whole bunch of windowing components and grouping and docking."
Wolf's engineering unit, which comprises around 1,700 developers, essentially serves as the platform team for the entire Bloomberg organization, serving everything from software development life cycle (SDLC) tooling and user interface frameworks, to managed services for multi-tenant environments, analytics and data science.
"The way I look at it is that my team's job is to support engineers. Many of those engineers work here and many of those work at our clients," says Wolf.
"You have to connect to hundreds of exchanges, and you have to normalise all sorts of data. That's kind of what we're in the business to do."
Sharing knowledge and best practice forms a central part of Bloomberg's developer environment. To promote this, the organization has established 'guilds' specialising in specific technologies and technical concepts.
These guilds, much like the medieval concept on which they are based, come together to solve problems and exchange tricks of the trade.
"The goal of it is really to bring together people who have deep expertise in different parts of the organization, to drive investment in the platform in some cases and to develop common standards and common approaches," says Wolf.
Some of this work is internal-facing, explains Wolf – for example, looking at how new programming language standards can be leveraged to upgrade Bloomberg's codebase.
Engaging with the tech community is also important for open-source projects like Python: not just for the benefit of Bloomberg's own development ecosystem, but also to that of the wider development community.
When it comes to open source you "have to be willing to get under the hood" and improve things for everyone, says Wolf: "We have to understand what's going on. We have to understand how we can make it better, and so I think that's almost a business necessity. You can't just use open source and kind of treat it as a black box."
Forking the codebase to add a new feature, for example, is useless if this feature is then not going to be contributed back to the community, and simply creates more headaches for development teams. "You're left with a part of that codebase, and as the codebase moves on, as it gets improvements and fixes, you're stuck with a fork," explains Wolf.
"Unless this is a core proprietary feature of your business, which it rarely is for us, don't we want to contribute that back and let other people build on top of it? Because now, your cost of integration is lower, you're able to move things forward, you're able to benefit from others contributing on top of that and making it better."
Of course, one caveat with open source is the often slow pace at which new features are added, with maintenance backlogs, codebase forks and differing priorities amongst contributors often slowing down development.
When it comes to balancing the maintenance of open-source code with releasing new features, Wolf says the notion that one can be prioritized over presents "a false choice".
"If you're on the edge of performance or capabilities…the only way you're going to be able to release new business features is if you keep up with the maintenance and you keep upgrading as the latest versions come out," he says.
"I don't think it's an either/or. I think maintenance and the upgrading and the reintegrating and upstreaming patches is a cost of the business. It's not a choice."