9 ms·

it never ceases to amaze me how the software engineering profession has very smart folks reimplement the same conceptual primitives over and over again. I'm cur

it never ceases to amaze me how the software engineering profession has very smart folks reimplement the same conceptual primitives over and over again. I'm curious if hospitals (if that's even analogous to a company) do similar things by having different processes to solve the same problem. I imagine this is used for Bloomberg (the terminal) and not Bloomberg (the website)? going back to the article - fantastic animations. I'm just as curious to how that was made as the queue itself.

BossingAround 3y ago
> I'm curious if hospitals (if that's even analogous to a company) do similar things by having different processes to solve the same problem. Of course they do, unless the processes are regulated by a country (such as handling highly addictive opiates in the US).
- quercusa 3y ago
  In the US, all hospitals are required to use electronic health records (EHRs) and most are implemented in Epic, the leading EHR system. But they are almost always electronic implementations of their old paper record systems, dating back to who-knows-when.
- thfuran 3y ago
  Yeah, pretty much any medium to large company is going to have a bunch of processes for doing things that any company that size needs to do and some more that are a bit more industry/domain specific but still basically the same as those at every other company in the space.
Sparkyte 3y ago
Part of this evolution is from funded development to opensource development. Then there is language variances like flavors so what ends up happening is a million different conceptual primitives that fundamentally the same. It isn't the same because of a few things. At the end of the day too it is also about how good the support is over the rest. If a new MQ can demonstrate better tooling nothing stops a company from adopting it.
- kapilvt 3y ago
  mainframe emulation is a thing, aka code change (Ala swap mq libraries) at enterprise scale, and supporting production without a migration path can very much stop adoption.
  - Sparkyte 3y ago
    That really depends on how the MQ integration is designed and whether or not the in queue data is persistent or doesn't get stale. In most cases an application doesn't like stale data so a long lived queue is rare. People who adopt something typically PoC before adoption.
dboreham 3y ago
What you say is true. But...this is Bloomberg so I think we can give them a pass and take a deeper look. I can't think of a more relevant company within which to develop messaging middleware.
- KnobbleMcKnees 3y ago
  It's cool to be cynical
- jdmichal 3y ago
  Exactly. Handling message queuing and distribution is likely a core capability for Bloomberg, so it makes a lot of sense for them to develop something tailored for their needs. LinkedIn did the same with the original Kafka development, where distributed eventual state consistency was a core capability. If anything, we should be thankful that they've decided to share it with the world.
marginalia_nu 3y ago
I feel like on the contrary there's an enormous cost attached to using prefab components that only kinda do what you need them to do. Shops that have embrace this philosophy have been some of the most inefficient ones I've ever encountered. Screens of yaml code was written to implement tasks that could have been performed with lines of programming code; and many man-years were spent implementing functions that copied fields from one object to another nearly but not quite identical object. It's a big driver of both complex and slow software. Often the adaptation layer necessary to get it to actually satisfy your needs rivals the size and complexity of the piece of existing solution code you're trying to leverage. Software that is built from the ground-up to your exact needs is often both faster and slimmer and more maintainable and suffers from far less dependency churn.
- wmfiv 3y ago
  Yeah. This works both ways. At small scale or early stage you should try like hell to work backwards from pre-existing components so that everything does exactly what you need them to do by definition. Eventually you outgrow that and it makes sense to build things that do exactly what you want because the incremental value is worth it.
- ecshafer 3y ago
  There is a balance to Not In House syndrome where you build everything yourself, and the opposite: everything should be vendored in. I am inclined to think that a healthy NIH syndrome is the better place to be. Companies which vendor everything move along at a snails pace, and often getting your outside product to work with internal needs is a huge years long endeavor, to the point just writing a decent version yourself that is exactly what you need is really useful.
  - marginalia_nu 3y ago
    NIH has shifted in meaning over time. It used to literally mean Not Invented Here. In the original sense, the NIH approach would be to invent a rivalling technique to the message broker. That is indeed a questionable idea.
vsareto 3y ago
>it never ceases to amaze me how the software engineering provision has very smart folks reimplement the same conceptual primitives over and over again. Well, no one cares, but I'm not saying that to be mean to dismissive, it's just that software production as an industry (esp. at a company like Bloomberg) can basically do whatever it wants because of low capital costs to produce something. Things like writing another queue system will have zero impact on the industry unless it's adopted widely (and cargo culted) and later made worse. Maybe I'm about to eat my shoe, but if a capable of team at Bloomberg wanted to reinvent something considered unnecessary in terms of industry need, they probably could if for no other reason that management allowing some indulgence in exchange for keeping talented people around is Worth It™.
- Scubabear68 3y ago
  Bloomberg had a history of inventing their own stuff going back to the first terminals. They had their own networking protocols and everything, when I was last there you could still see remnants in how machines were named. They do adopt a lot of industry stuff, but it is always heavily modified. And of course they love “Invented Here” as a corporate tradition going all the way back to the beginning. It’s actually nice from a developer perspective, the R&D group is highly valued by management.
- throwaway2037 3y ago
  You wrote: low capital costs to produce something I don't understand that phrase. Probably a large team of very well paid engineers developed this product. Bloomberg is well-known in the industry for paying well. "[L]ow capital costs"? This software probably cost millions in salaries to build, and millions more to maintain over the next 10+ years.
  - vsareto 3y ago
    >You wrote: low capital costs to produce something >I don't understand that phrase. You don't need a big factory with large capital costs to make or distribute software. You're only paying people, and salaries are not capital investments.
deleted 3y ago
[deleted]
jrvarela56 3y ago
Two reasons I can think of: 1. It is easier to implement from scratch than understand and modify: we see this everyday at a way smaller scale with libraries/classes/functions. Not saying this is optimal but this is a driver for sure. 2. Recruiting: some devs love doing this. Fancy OSS project to put on your resume, some actually believe there's unfulfilled need, you get people like us discussing it (otherwise we wouldn't be thinking about Bloomberg).
- erulabs 3y ago
  It's a somewhat difficult argument to say that it's easier to build from scratch, but I hear what you're saying. At any rate, it is absolutely more fun to build from scratch. I've polled developers about what part of software development they hate, and in general, it's deployment and maintenance (ie: devops). Using a off-the-shelf-component means that the developer only gets to do the un-fun part: installing, configuring, productionizing. If they code their own solution, they get to spend a few weeks coding!
paxys 3y ago
Smart people solving "solved problems" over and over again is exactly how the tech industry progresses. Meanwhile other industries are stuck with processes from fifty years ago because "it has always been done this way", and anyone even suggesting the slightest bit of change is a heretic.
Scubabear68 3y ago
When I left Bloomberg around 7 years ago Kafka was being aggressively rolled out and there was a lot of interest in data streaming tech in general. I am wondering if they ran into performance or resource usage issues with Kafka at scale, and decided to roll their own for use cases that better fit their workloads. Bloomberg does have vast backend infrastructure for moving around / computing data which the Terminal is a consumer of.
jjahdhnmko 3y ago
I've had to do this mostly because of batshit crazy rules many large companies have about how all software has to be supported. The issue there being the definition of supported in the eyes of clueless auditor types. If software is written 100% externally, but the vendor only wrote 10% of it and is transparently taking 90% from an open source project so they can sell fraudulent support (assuming they don't have people contributing to the open source project here), that counts as supported. If it is written 100% internally, even if it is built on top of some ancient internal codebase that nobody can figure out and has been in life support mode for 20 years, then it counts as supported. But if its written 50% internally and 50% of it came from an external open source library with a BSD license, and you are a major contributor to that project, then it is considered unsupported and you get in trouble. This is how you end up with security issues because some sysadmin decided they had to roll-their-own crypto library or authentication system, because its better to have an unknown implementation show up on a scanner than a known one that has a list of CVEs that can be checked.
gorbachev 3y ago
I don't know for sure, but there's a fair chance BlazingMQ precdates Kafka, at least the OSS version of it, by several years.

BossingAround 3y ago

> I'm curious if hospitals (if that's even analogous to a company) do similar things by having different processes to solve the same problem. Of course they do, unless the processes are regulated by a country (such as handling highly addictive opiates in the US).

quercusa 3y ago
In the US, all hospitals are required to use electronic health records (EHRs) and most are implemented in Epic, the leading EHR system. But they are almost always electronic implementations of their old paper record systems, dating back to who-knows-when.
thfuran 3y ago
Yeah, pretty much any medium to large company is going to have a bunch of processes for doing things that any company that size needs to do and some more that are a bit more industry/domain specific but still basically the same as those at every other company in the space.

Sparkyte 3y ago

Part of this evolution is from funded development to opensource development. Then there is language variances like flavors so what ends up happening is a million different conceptual primitives that fundamentally the same. It isn't the same because of a few things. At the end of the day too it is also about how good the support is over the rest. If a new MQ can demonstrate better tooling nothing stops a company from adopting it.

kapilvt 3y ago
mainframe emulation is a thing, aka code change (Ala swap mq libraries) at enterprise scale, and supporting production without a migration path can very much stop adoption.
- Sparkyte 3y ago
  That really depends on how the MQ integration is designed and whether or not the in queue data is persistent or doesn't get stale. In most cases an application doesn't like stale data so a long lived queue is rare. People who adopt something typically PoC before adoption.

dboreham 3y ago

What you say is true. But...this is Bloomberg so I think we can give them a pass and take a deeper look. I can't think of a more relevant company within which to develop messaging middleware.

KnobbleMcKnees 3y ago
It's cool to be cynical
jdmichal 3y ago
Exactly. Handling message queuing and distribution is likely a core capability for Bloomberg, so it makes a lot of sense for them to develop something tailored for their needs. LinkedIn did the same with the original Kafka development, where distributed eventual state consistency was a core capability. If anything, we should be thankful that they've decided to share it with the world.

marginalia_nu 3y ago

I feel like on the contrary there's an enormous cost attached to using prefab components that only kinda do what you need them to do. Shops that have embrace this philosophy have been some of the most inefficient ones I've ever encountered. Screens of yaml code was written to implement tasks that could have been performed with lines of programming code; and many man-years were spent implementing functions that copied fields from one object to another nearly but not quite identical object. It's a big driver of both complex and slow software. Often the adaptation layer necessary to get it to actually satisfy your needs rivals the size and complexity of the piece of existing solution code you're trying to leverage. Software that is built from the ground-up to your exact needs is often both faster and slimmer and more maintainable and suffers from far less dependency churn.

wmfiv 3y ago
Yeah. This works both ways. At small scale or early stage you should try like hell to work backwards from pre-existing components so that everything does exactly what you need them to do by definition. Eventually you outgrow that and it makes sense to build things that do exactly what you want because the incremental value is worth it.
ecshafer 3y ago
There is a balance to Not In House syndrome where you build everything yourself, and the opposite: everything should be vendored in. I am inclined to think that a healthy NIH syndrome is the better place to be. Companies which vendor everything move along at a snails pace, and often getting your outside product to work with internal needs is a huge years long endeavor, to the point just writing a decent version yourself that is exactly what you need is really useful.
- marginalia_nu 3y ago
  NIH has shifted in meaning over time. It used to literally mean Not Invented Here. In the original sense, the NIH approach would be to invent a rivalling technique to the message broker. That is indeed a questionable idea.

vsareto 3y ago

>it never ceases to amaze me how the software engineering provision has very smart folks reimplement the same conceptual primitives over and over again. Well, no one cares, but I'm not saying that to be mean to dismissive, it's just that software production as an industry (esp. at a company like Bloomberg) can basically do whatever it wants because of low capital costs to produce something. Things like writing another queue system will have zero impact on the industry unless it's adopted widely (and cargo culted) and later made worse. Maybe I'm about to eat my shoe, but if a capable of team at Bloomberg wanted to reinvent something considered unnecessary in terms of industry need, they probably could if for no other reason that management allowing some indulgence in exchange for keeping talented people around is Worth It™.

Scubabear68 3y ago
Bloomberg had a history of inventing their own stuff going back to the first terminals. They had their own networking protocols and everything, when I was last there you could still see remnants in how machines were named. They do adopt a lot of industry stuff, but it is always heavily modified. And of course they love “Invented Here” as a corporate tradition going all the way back to the beginning. It’s actually nice from a developer perspective, the R&D group is highly valued by management.
throwaway2037 3y ago
You wrote: low capital costs to produce something I don't understand that phrase. Probably a large team of very well paid engineers developed this product. Bloomberg is well-known in the industry for paying well. "[L]ow capital costs"? This software probably cost millions in salaries to build, and millions more to maintain over the next 10+ years.
- vsareto 3y ago
  >You wrote: low capital costs to produce something >I don't understand that phrase. You don't need a big factory with large capital costs to make or distribute software. You're only paying people, and salaries are not capital investments.

deleted 3y ago

[deleted]

jrvarela56 3y ago

Two reasons I can think of: 1. It is easier to implement from scratch than understand and modify: we see this everyday at a way smaller scale with libraries/classes/functions. Not saying this is optimal but this is a driver for sure. 2. Recruiting: some devs love doing this. Fancy OSS project to put on your resume, some actually believe there's unfulfilled need, you get people like us discussing it (otherwise we wouldn't be thinking about Bloomberg).

erulabs 3y ago
It's a somewhat difficult argument to say that it's easier to build from scratch, but I hear what you're saying. At any rate, it is absolutely more fun to build from scratch. I've polled developers about what part of software development they hate, and in general, it's deployment and maintenance (ie: devops). Using a off-the-shelf-component means that the developer only gets to do the un-fun part: installing, configuring, productionizing. If they code their own solution, they get to spend a few weeks coding!

paxys 3y ago

Smart people solving "solved problems" over and over again is exactly how the tech industry progresses. Meanwhile other industries are stuck with processes from fifty years ago because "it has always been done this way", and anyone even suggesting the slightest bit of change is a heretic.

Scubabear68 3y ago

When I left Bloomberg around 7 years ago Kafka was being aggressively rolled out and there was a lot of interest in data streaming tech in general. I am wondering if they ran into performance or resource usage issues with Kafka at scale, and decided to roll their own for use cases that better fit their workloads. Bloomberg does have vast backend infrastructure for moving around / computing data which the Terminal is a consumer of.

jjahdhnmko 3y ago

I've had to do this mostly because of batshit crazy rules many large companies have about how all software has to be supported. The issue there being the definition of supported in the eyes of clueless auditor types. If software is written 100% externally, but the vendor only wrote 10% of it and is transparently taking 90% from an open source project so they can sell fraudulent support (assuming they don't have people contributing to the open source project here), that counts as supported. If it is written 100% internally, even if it is built on top of some ancient internal codebase that nobody can figure out and has been in life support mode for 20 years, then it counts as supported. But if its written 50% internally and 50% of it came from an external open source library with a BSD license, and you are a major contributor to that project, then it is considered unsupported and you get in trouble. This is how you end up with security issues because some sysadmin decided they had to roll-their-own crypto library or authentication system, because its better to have an unknown implementation show up on a scanner than a known one that has a list of CVEs that can be checked.

gorbachev 3y ago

I don't know for sure, but there's a fair chance BlazingMQ precdates Kafka, at least the OSS version of it, by several years.