It turns out, in my opinion, we solved most problems in software engineering decades ago. All this high flying non-sense, web3 petabyte scale cloud powered type safe microservices, is pointless navel gazing. Agile is pointless navel gazing at least in it's current incarnation. Our entire industry has been mired in bullshit that hamstrings us.
There's also a tremendous difference in developers. Developers even two decades ago were near top of their game because they had to be. They didn't have kubernetes-docker-CI/CD-SRE-devops to protect them. The result? Far better, far more reliable code.
Any idiot can write software. Changing languages won't save you. A good programmer can make any language into a good language - and as it turns out 30 years ago we did it right. If they're only encountering scaling issues now that isn't a knock against them. It goes to show just how well they took "primitive" tools and made a system that simply works. Asking a modern dev team to produce a system that simply works often requires several months of planning, two full time product managers, a tech lead, several weeks of architecting, and approval (in blood) from the CTO who somehow has to involve themselves in literally anything and everything. Let's not forget we have to get it spun up with terraform so it's in the cloud and that'll take a request to SRE and possibly even dev-ops to get done. By the time the developers even get to write code, the deadline already arrived! We are comical facsimiles of our fore-developers and frankly should feel ashamed.
22 years ago, I was working on software to run a single state's fish and game licensing. We had 4 product managers (backend, admin, retail-front-end, consumer-web), 6-8 architects, at least 10 project managers and probably 70+ engineers, 30+ QA engineers. It had its specs written by a separate group for 6 months, that was then thrown away, and then rebuilt using Rational Unified Process. It was 10x over budget money-wise and 3x time wise. It took around 3 years to release to the public.
Those four products,
back-end team wrote in pure Oracle stored procedures.
the retail-front-end team wrote in 95% JSPs, with a small library of java functions. When logic needed to split amoungst 4 types of licenses, they copied pasted an entire 2000 line JSP over and changed minor code, then just forwarded to the right JSP depending on the type.
The consumer-web code was written in Perl, which needed to call functions in the retail-front-end, so the solution was to wrap the JSP code, call them with, what we would call now, mocked request/response objects. The PERL software called this mess using SOAP. So care had to be strip down every interface to use primitive objects so PERL and Java could talk.
The admin-code, my team, wrote in our own Java MVC framework, Struts was just created. What started as a web-project turned into a 'recreate the mainframe interface using html' though.
So yeah, 30 years ago, we did things right, or perhaps you meant 50 years ago?
Put together, the daily weekday ridership is probably closer to ~14M, pre-COVID. And that's not including some of the knock-on computational costs, like the radio network that links the MTA's buses or the in-system transfer rules.
You might think this is a clever take but it's really not far from the truth. They NEED a revamp on a modern tech stack so they can use the trains, electronics, and technology trains in the rest of the world run on.
In other words: the things that are currently falling apart (the physical relays, for example) are almost completely disconnected from fare collection (which is what the article’s about). The latter runs pretty well; replacing it with a modern tech stack rather than the current incremental approach wouldn’t have many benefits.
Arguably, the most advanced "tech stack" for moving trains around rail systems today (at scale, with the highest safety rating) is based around the Sicas ECC electronic interlocking by Siemens.
However, this article is merely about the technology used for collection of fares for the NYC metro rail system.
> Most subway services cannot significantly increase their frequencies during rush hours, except for the 1, G, J/Z, L, and M trains (the L service already is automated with CBTC).
> However, even without CBTC, the system is currently retrofitted to operate at frequencies of up to 60 trains per hour (tph) on the IND Queens Boulevard Line (30 tph on each of the local and express pairs of tracks made possible by the Jamaica–179th Street terminal, which has four sidings past the terminal for each set of tracks) and 33 tph on the IRT Flushing Line.
https://en.wikipedia.org/wiki/Signaling_of_the_New_York_City...
https://web.archive.org/web/20071012190431/http://pages.prod...
The power and energy efficiency of today's computers is wasted on commercial surveillance and draining advertising budgets. Let us pray that someone discovers a more effective means of advertising than the computer. The 2018 Netflix series "Maniac" seemed to hint at this alternate future.
IIRC, they eventually dumped DAE, but had to deliver something before CORBA (or DSOM) was a thing.
Imagine if we required $ billions in public resources to run other mundane software projects people came to rely on.