Rent's due today, thank heavens I just got paid.
I don't set up standing orders, got burned once with unarranged overdraft fees, that wasn't a good mont...
The thing is, these mantras are always taken out of context.
“Memory is cheap” is in comparison to other options. For example, if you have a the choice between optimizing for CPU or memory, you should optimize for CPU almost every time because it’s a lot cheaper to add more RAM than add more CPU.
But for some reason, we’ve taken this to mean, “I don’t need to optimize memory or CPU because I can just upgrade them.” That’s only true until it isn’t, and it’s generally easier to optimize things as you go than optimize once everything is broken.
Good post. I really don’t understand how apps have gotten so terrible.
The app I work on is slow, but that’s because we’re doing pretty heavy things (3D canvas stuff), but even then we do a really bad job of lazy loading stuff (e.g. images used for that 3D stuff are loaded way before you get to the 3D part, and many users don’t use the 3D feature at all in a session).
But at least we have an excuse. Why does the bank app take forever to load when it just needs to query around balances and submit tasks to their backend to process? That should be incredibly lightweight.
Also the only time I’ve heard “memory is cheap” used IRL was in backend development. Because it’s cheap to scale up memory on your servers, but not cheap to spend a day or 2 hyperoptimizing a solution that’s fast enough. Dev time is expensive.
Or for workstations. It’s a lot cheaper to add a stick of RAM to a workstation than optimize workflow a bit.
There are many cases where RAM is not cheap:
mobile apps
end user machines - most people won’t add that stick of RAM
macOS apps - pretty much all Apple products use soldered RAM now
If you control the machine, RAM is cheap, until it isn’t. If you don’t control the machine, you should always keep an eye on RAM, because once the complaints start coming in, you’ve already started losing customers.
MacOS has weirdly fast paging and shit, you don’t feel the lack of RAM immediately. But in the long run it’ll kill your (also soldered) SSD so that’s even worse for heavy users.
I think phone apps have more to play with as well nowadays. A Galaxy A55 can have 12 gigs of RAM now. That used to be considered overkill for even flagships, let alone midrange phones, just a few years ago. Plus both operating systems will suspend apps running in the background when needed.
My phone is pretty recent and has 8GB RAM, and it’s still fairly common to find phones with 4GB RAM. You really can’t rely on a consistent amount of RAM, so being careful with memory is still important.
I honestly think a big part of it is the hacky nature of the self-made dev. There’s an emphasis on getting it working instead of getting it right. Work fast, crash fast, and get it limping along faster.
I might know the answer to your last point. I have experience working with financial services and large old institutions.
In short the front end is likely lighting fast and lightweight but the services it relies are incredibly old and outdated. Like mainframes running COBOL old. There is likely some abstraction but there are also likely literal decades of technical debt. Sometimes a call to understand what should be simple like what accounts does this client have might need to call multiple legacy systems that were integrated over the course of multiple acquisitions.
Believe it or not but I’ve seen the mobile apps be required to use totally different abstraction layers than websites, usually due to different authentication and access management methods.
“Back-end” is often relative when talking about these old systems. There are sometimes multiple layers of abstraction with different business logic built into each layer.
It’s fixable of course, but it is costly to unwind 30-40 years of bad technical decisions made by business people who never understood the systems they were making decisions for.
That sounds like a cop-out to me. Surely they could have snapshots of data in a more reasonable system to make common operations fast (mostly querying data), while keeping the old systems as the source of truth, no? We do that, and we have far fewer customers than a major bank does…
The thing is, these mantras are always taken out of context.
“Memory is cheap” is in comparison to other options. For example, if you have a the choice between optimizing for CPU or memory, you should optimize for CPU almost every time because it’s a lot cheaper to add more RAM than add more CPU.
But for some reason, we’ve taken this to mean, “I don’t need to optimize memory or CPU because I can just upgrade them.” That’s only true until it isn’t, and it’s generally easier to optimize things as you go than optimize once everything is broken.
Good post. I really don’t understand how apps have gotten so terrible.
The app I work on is slow, but that’s because we’re doing pretty heavy things (3D canvas stuff), but even then we do a really bad job of lazy loading stuff (e.g. images used for that 3D stuff are loaded way before you get to the 3D part, and many users don’t use the 3D feature at all in a session).
But at least we have an excuse. Why does the bank app take forever to load when it just needs to query around balances and submit tasks to their backend to process? That should be incredibly lightweight.
Also the only time I’ve heard “memory is cheap” used IRL was in backend development. Because it’s cheap to scale up memory on your servers, but not cheap to spend a day or 2 hyperoptimizing a solution that’s fast enough. Dev time is expensive.
Or for workstations. It’s a lot cheaper to add a stick of RAM to a workstation than optimize workflow a bit.
There are many cases where RAM is not cheap:
If you control the machine, RAM is cheap, until it isn’t. If you don’t control the machine, you should always keep an eye on RAM, because once the complaints start coming in, you’ve already started losing customers.
MacOS has weirdly fast paging and shit, you don’t feel the lack of RAM immediately. But in the long run it’ll kill your (also soldered) SSD so that’s even worse for heavy users.
I think phone apps have more to play with as well nowadays. A Galaxy A55 can have 12 gigs of RAM now. That used to be considered overkill for even flagships, let alone midrange phones, just a few years ago. Plus both operating systems will suspend apps running in the background when needed.
My phone is pretty recent and has 8GB RAM, and it’s still fairly common to find phones with 4GB RAM. You really can’t rely on a consistent amount of RAM, so being careful with memory is still important.
I honestly think a big part of it is the hacky nature of the self-made dev. There’s an emphasis on getting it working instead of getting it right. Work fast, crash fast, and get it limping along faster.
I might know the answer to your last point. I have experience working with financial services and large old institutions.
In short the front end is likely lighting fast and lightweight but the services it relies are incredibly old and outdated. Like mainframes running COBOL old. There is likely some abstraction but there are also likely literal decades of technical debt. Sometimes a call to understand what should be simple like what accounts does this client have might need to call multiple legacy systems that were integrated over the course of multiple acquisitions.
For my bank the website works fast, but app does not. So an old backend is not always the issue.
Believe it or not but I’ve seen the mobile apps be required to use totally different abstraction layers than websites, usually due to different authentication and access management methods.
“Back-end” is often relative when talking about these old systems. There are sometimes multiple layers of abstraction with different business logic built into each layer.
It’s fixable of course, but it is costly to unwind 30-40 years of bad technical decisions made by business people who never understood the systems they were making decisions for.
That sounds like a cop-out to me. Surely they could have snapshots of data in a more reasonable system to make common operations fast (mostly querying data), while keeping the old systems as the source of truth, no? We do that, and we have far fewer customers than a major bank does…
Major bank
There’s your answer