DefinitelyNotAPhone [he/him]

  • 0 Posts
  • 9 Comments
Joined 4 years ago
cake
Cake day: July 29th, 2020

help-circle


  • You have to sell a new phone every 12-18 months, because otherwise the shareholders eat you alive for not chasing infinite profits. You have to differentiate your new phone from your last phone, even if there are no meaningful changes to be made and the last phone was good enough for everything anyone would ever use it for (as was the one before it, and the one before that, and etc etc). You have to push for people to buy the new phone, because otherwise you don’t make money.

    So you tell the engineers to bump up the clock speeds on the processor 5-10% so you can market it as being faster. You market the phone as being revolutionary for using the USB connector that was forced on you by regulators because your proprietary one was filling landfills with e-waste and pretend like it was your brilliant idea all along. You make sure to limit that USB connector to speeds that were outdated 10 years ago purely so you have a built-in ‘upgrade’ for your next phone where you fix the thing that shouldn’t have been a problem to begin with.

    And then you realize your phone overheats because you overclocked the processor, all to squeeze extra performance out of a chip that 99.9999999999% of users will never notice or need. You’ve made the user experience of your phone worse purely so you could pursue an untenable goal of endless profit, a pattern you will repeat every 12-18 months for the rest of eternity or until the climate wars claim your life.

    Only the most sane and functional economic system.



  • Well, I’d rather the day be sooner than later.

    Agreed, but we’re not the ones making the decision. And the people who are have two options: move forward with a risky, expensive, and potentially career-ending move with no benefits other than the system being a little more maintainable, or continuing on with business-as-usual and earning massive sums of money they can use to buy a bigger yacht next year. It’s a pretty obvious decision, and the consequences will probably fall on whoever takes over after they move on or retire, so who cares about the long term consequences?

    You run months and months of simulated transactions on the new code until you get an adequate amount of bugs fixed.

    The stakes in financial services is so much higher than typical software. If some API has 0.01% downtime or errors, nobody gives a shit. If your bank drops 1 out of every 1000 transactions, people lose their life savings. Even the most stringent of testing and staging environments don’t guarantee the level of accuracy required without truly monstrous sums of money being thrown at it, which leads us back to my point above about risk vs yachts.

    There will come a time when these old COBOL machines will just straight die, and they can’t be assed to keep making new hardware for them.

    Contrary to popular belief, most mainframes are pretty new machines. IBM is basically afloat purely because giant banks and government institutions would rather just shell out a few hundred thousand every few years for a new, better Z-frame than going through the nightmare that is a migration.

    If you’re starting to think “wow, this system is doomed to collapse under its own weight and the people in charge are actively incentivized to not do anything about it,” then you’re paying attention and should probably start extending that thought process to everything else around you on a daily basis.





  • There’s the other half of this problem, which is that the kind of code that LLMs are relatively good at pumping out with some degree of correctness are almost always the bits of code that aren’t difficult to begin with. A sorting algorithm on command is nice, but if you’re working on any kind of novel implementation then the hard bits are the business logic which in all likelihood has never been written before and is either sensitive information or just convoluted enough to make turning into a prompt difficult. You still have to have coders who understand architecture and converting requirements into raw logic to do that even with the LLMs.