Indiana bakery still using Commodore 64s originally released in 1982 as cash registers — Hilligoss Bakery in Brownsburg sticks to the BASICs
Indiana bakery still using Commodore 64s originally released in 1982 as cash registers — Hilligoss Bakery in Brownsburg sticks to the BASICs
You're viewing a single thread.
Why create e-waste and spend money you don't have to when your existing retro hardware not only works fine but gives customers something to talk about?
I wish more people thought this way.
No, I'm all against e-waste, but the whole "if it ain't broke" mentality is asinine, that's how we end up with bullshit like the entire financial system of the country being underpinned by an ancient mainframe program written in COBOL and is a huge reason we STILL need to wait DAYS for transactions to process because it can't handle Real-time transactions. That's the result of a generation or 2 of executives going "If iT aINt BrOKe"
Retired that shit and repurpose it to teach kids the BASICs of programming or something.
The quote should be changed to "If it ain't broke, evaluate the modern options available and determine if it will truly improve things and switch to that if so"
That's not an example of working fine, now is it?
I hope whatever put you in such a foul mood gets better.
That's not an example of working fine, now is it?
Try convincing non-IT executives of that who absolutely LOVES that stupid phrase when trying to get funding approved to update some 20 year old system sometime
Exec:"Why update and spend money, when the old system works fine?"
Well it technically works, but our customers expect a modernized system that doe---
Exec: "So it works then, iF iT AInT BrOkE..."
Well it technically works...
Nope. There's your problem. You don't start with any version of "it works." You begin with "here's how the old system is costing us money, and here's how much more money the new system will increase profits." Tech debt is the catchphrase of the moment, and you can describe it in financial terms executives understand. Tech debt charges interest, and the interes of delaying payments into infrastructure will outpace the money saved by a significant margin. That's why spending the money now will decrease friction, reduce churn, and streamline onboarding of new accounts. This is what our competitors are doing, and this is how we can do it better.
That's the pitch. If your argument is "it works, but we can do better," that makes it sound like you're putting extra padding in the first class seats. The real answer is it works because IT is working in a constant state of panic and the job of 10 engineers is being done by two interns and a roll of duct tape. To an executive, that sounds like efficiency, because they don't give a shit about you. Number goes up, that's their focus.
Damn! You really know this game!
^ This is how you sell IT.
What are you talking about? The old, white men in charge absolutely think it's "working fine"! That's the entire argument behind "security through obscurity", they're just out of touch and don't want progress...
the reason transactions take so long is because of compliance. COBOL, CICS (the tramsaction manager) and mainframes themselves are constantly being updated and optimized because no flavor of the week in the last three decades has been able to handle the throughput needed by the companies that still use them. if anything in the tech stack at banks is slowing down your paycheck getting cashed, it's the small army of nodeJS servers whose entire codebase gets rewritten every six months because some exec thinks COBOL isn't sexy enough and we can get rid of it we say the word "agile" enough. the fortune 500 has been planning on being "off the mainframe in the next 3 years" since the 90s
Yes. COBOL instructions map nearly directly (something like 1:4) to machine language instructions on the mainframe chipsets it was built for. It strongly encourages stateless procedures with its design, and has some other benefits that align closely with the financial sector. You can drop down to assembly as a hot spot optimization if you really need to.
The industry could replace COBOL, but its replacement would wind up looking a lot like COBOL at the code structure level, or a slightly nicer language would have an intermediate transpile step into COBOL or something similar. Probably no performance gains. Perhaps some usability gains. Not enough to sell it as a rewrite.
Reality is its use will probably outlive us all.
In the meantime let's fire up some AS400 (yes I know, it's called IBM i or whatever now nobody cares)
My last company was selling IBMi's and writing the code for them. Customer's didn't like our GUI product. They wanted rock-solid, green screen menus.
To me it's the tech equivalent of painting yourself into a corner, sure it works at the moment but what are the hidden costs of sticking on a dead end technology? What's the upgrade path from a C64, a C128? What happens if a chip on the circuitboard fails, or the power supply? Can't exactly order a new one, they stopped making them over 30 years ago and the company has been defunct for basically the same amount of time.
I wish I could remember more details, but I remember years ago reading about a company that had a core product that depended on an old 286 era laptop with a special software/hardware combo for maintenance, and all I could think of was that a single accidental bump of a table was all it'd take to shut down that product for months until they could find the exact replacement.
Actually c64 replacement parts are pretty affordably available these days and easily maintainable due to the comparable simplicity Vs modern computing hardware. One of the advantages of the age of hobbiest computing - the designs used widely available ICs that you can just buy and assemble on your kitchen table with a soldering iron.