>When someone smugly says "micro-optimisations don't matter, networks are great, CPUs fast and memory plentiful", proceeds to make an app one degree more complicated than Hello World use 4 GB of RAM and drain half my battery, I'm having dark thoughts.
TBH I don't think those are the same person. Lots of apps glued together by developers who never think about micro-optimizations, maybe under severe time crunches without QA teams or PMs who don't care and managers who chose to go with the lowest bidder, but sure, let's blame the developer.
I look at video game forums and subreddits and see the same logic when they don't like something; like, you honestly don't know how software or games are built if you are solely blaming the devs at this point.
> I look at video game forums and subreddits and see the same logic when they don't like something; like, you honestly don't know how software or games are built if you are solely blaming the devs at this point.
I always read "devs" in video game discussions as referring to the company which owns the development work rather than the programmers at the company. If someone wrote a comment, "The devs don't let their programmers do their job" on a video game forum, I would logically expand "devs" to "managers at the development company". I totally see how that's not intuitive to a developer, though; perhaps that comes from my interest in video games before I ever became a programmer.
it's the ones who rave "microoptimizations matter goddamn it!" who will try to shave 150ms off the "send money" screen of the banking app and not notice that the app takes up 750MB of storage.
Or spend 2 days shaving off 150ms that no one asked for when we have much more pressing features. I don't care if the button is faster if the action it kicks off doesn't work. The road to hell and all of that...
It's kind of funny because I'm not 100% sure which one you are talking about. I assume it's the time, storage be damned. I agree that's probably what users will say but in that world (picking speed over storage) we will see this exact same article posted with a stronger focus on the app size (the post does make at least 1 mention of app size).
But it's usually the other way around? Lightweight usually means faster. It's takes less bandwidth, it can be cached more efficiently at network edges and in CPU cache.
There exist tradeoffs that might make bulkier applications worth it, like faster and cheaper development I guess.
Add in the issue of change for the sake of change. I'm older, and wear hearing aids. Today, there was an app update that added nothing new, but it did rearrange the GUI. It's not better, it's just different.
Being a techie, it's no problem for me. But: how many nontechnical, elderly people are going to be lost?
Stupid management? New UI designer wanting to prove themselves? Don't know, don't care - I played dumb and sent in a confused complaint.
it's actually kind of comical to think of all the IT departments out there forcing the entire company to beta-test a new webapp every five-years solely because they're either bored or afraid of not looking busy. I would rather they just spend 90% of their work-week playing WoW and only show up when there's a new problem but i can also understand the pressure to look busy and not let some overpaid exec like elon musk see how not-busy they are and come up with the bright idea that since the computers work 90% of the time without manual intervention that means you only need 10% of your staff.
My US bank is hilariously slow to change and I love it, debit card doesn't have that wireless thingy, the website did change recently, but it had 2000s dot com boom vibes before, and a rate of change of once every 20 years is fine, especially since they sent copious amount of emails and followed up to make sure everyone was able to do stuff.
In general I think the US is very respectful of slow change, hell you file taxes by sending mail or faxes!
I do find it ridiculous just how big mobile applications have gotten. Why does the UPS app have to be over 100 MB? It's got maybe a couple dozen unique screens visible to the user, few image assets, and mostly just settings, and account login, text entry, and pulling results from the web. It's not unique to UPS, most of the apps on my phone are of that size magnitude (Amazon is almost a quarter gigabyte with data), it was just a convenient choice because of how simple the app seems.
That being said, the oddest-to-me thing in this article is a bank call center not being open 24/7.
I don't know about iOS, but when I look at big APKs on Android, what I usually see is a good number of images that are essentially repeated 3-4 times for different dpi ranges, and localized text, in utf-16, for many languages, uncompressed. I think I saw something recently about Google providing tools to compressing localized text, but I may be misremembering. The logic for storing localized text uncompressed is something about mmaping the data and accessing by offset for efficiency, but when an app supports a majority of the world's living written languages, and users tend to support only one or two, the storage cost doesn't make sense. At one point, Google Play tried to do localization packs, but it never actually made sense to use, so nobody does. I know proprietary options exist to compress localized text in apks, but being part of the default system is important.
</dated rant> (edit: my information is old, and perhaps hopefully outdated)
Android as a platform definitely supports only downloading the image assets etc relevant for your specific device - whether applications are taking advantage of this is a different question https://developer.android.com/guide/app-bundle/app-bundle-fo...
Uhm I think Google Play now always only sends you only the resources for your device and language? (except for the few old apps that are exempt from giving the signing key to Google)
Oh oh!! Let me guess!! I don't do mobile but have looked into it. And the guy behind me is doing an app too. Everyone wants to minimize development effort so they pick a framework that will spit out both iOS and Android apps. It's the framework that ends up bloating everything. Maybe? That doesn't explain "why", it just pushes it off the app developer onto someone else.
It seems always so weird, when you compare those to some older well optimized desktop softwares. Some with decent number of features being in under 10 megabyte range...
I don't expect it to fetch everything from a server every time, not every app needs to be only a browser serving remote content. I just expect a simple app to be simple in size, there just isn't much going on in this app.
The app is only downloaded once every month or two for the usual updates. It happens in the background when you aren't using your phone anyway, and by default both OSes will wait until you're on wifi too.
App size doesn't matter much in the actual use of the app, especially if you're using it often.
... except that the complete collection of everything the UPS app needs to execute or display, in order to actually fulfill its function, summed up throughout all of its operation in every possible mode, probably fits in 1MB. If there's 100MB of stuff you store or potentially download for a shipping app, then you're including something that doesn't add value for the user.
Start by removing all the pictures, videos, and similar. Then take out the analytics crap. Then, if your app is still big, figure out what's wrong with your code.
My experience is that it doesn't take longer. It just takes knowing that a lot of "best practices" are actually not (both dev and management need to know this, or at least management needs to trust dev).
Is 100MB a lot? It feels like a decent size, yet if you consider that a hello world weighs 17kb, it feels like a lot without an explanation.
I'd venture a guess that there's a fat dependency chain based on the need to avoid reinventing the wheel all the while not paying for software dependencies.
NPM import npm2
npm2 install obscuredependency
And npm2 doing full dependency duplication to avoid version conflicts, leaving like 2 or 3 versions of each base library, that kind of stuff
100 MB is a lot for a simple application. On the Android phone I had in the mid-2010s, that would have taken up a ridiculous amount of my precious little storage.
That chain of dependencies does fall in line with the message (regardless of how widely it applies) of "modern developers don't care about efficiency".
In my experience a lot of these kinds of messed up priorities tend to come from managers and PMs, not engineers. A lot of engineers would find it a fun challenge to support old devices and optimize the hell out of your app, but they just aren't given the opportunity.
Right on the money. We get paid to add more pretty buttons, rather than make sure exceptions risen by existing buttons are handled gracefuly at no cost to UX.
Use cases are hypothetical scenarios worth getting mad over. They are THE things we should give a shit about. When somebody on my team suggests something that's user-hostile in 1% of cases because they don't give a shit, I'm not going to just say, "well, I better not have negative emotions". That's how we get the garbage world.
Repetitive focus on negative thoughts or hypothetical situations could be a symptom of anxiety or anger. Doesn’t have anything to do with tech in my experience, more with mental health in general.
I have definitely been in dozens upon dozens upon dozens of situations where a website or app struggled to do something that my dad's PC in the 90s could do fast enough for the modem to be the only bottleneck. And even then the P1 with the modem that ran into the phone line probably still wins out, which is disgusting given that its entire disk was smaller than the RAM on my phone.
ROPs vulernabilities and lack of linux compatibility notwithstanding, i swear flash wasn't even half as bad as modern web crap.
It's a very sophisticated rhetorical technique called "attacking a strawman." They've already won all the normal arguments they could find, so they create a strawman and attack it.
There is one way to pay rent which requires no RAM or CPU cycles: write a check, and mail it. In my experience, most payees accept the date a check is mailed as the date of payment. (There may be exceptions to this, and I'm not sure what, if any, protections the law provides, so it may not be a valid fallback.)
In general society needs to maintain these low-tech fallbacks to high-tech "improvements". For example, we should keep taxis (that can be flagged down with your hand, and paid for in cash) and not rely solely on Uber, Lyft, etc. We should keep the ability to order from a human at restaurants. We must resist putting the smartphone into the unreplacable critical path of human life. To do so values technology above the value of human life.
It's already happening today where children and the elderly need a fully-charged, fully-patched secure device with multiple apps, passwords and two-factor authentication, just to receive health care.
I think coins need to be banned full stop. At current prices, you can probably just do a paper quarter and create a law to allow cash payments to be rounded down to the nearest quarter. Most business would be ok with this since they can avoid the credit card fees. I think we should also go plastic like canada, the bills are easier to count, harder to get dirty, and harder to get lost or crumpled. I'd also imagine itd also be harder to counterfeit and easier to track.
In general one should never agree to use an app to pay rent, since these apps are often wrapped in terms and conditions. You should always just pay your rent by check, cash, or money order. Every jurisdiction in America requires lessors to accept these.
Not quite. According to a quick search [1]: "Under California law, it's illegal for a landlord to require cash and/or electronic deposits as the sole methods to pay rent.1 Landlords must allow a tenant to pay rent using at least one of these other options as well: check, cashier's check, or money order."
When I lived in CA I had a landlord that demanded cashier's check. Do you know how annoying those are to get?
I could have also paid cash but then I'd take the risk that the cash, dropped in a mailbox, would "go missing".
most devs complain about management tying their hands but more often than not they have a great deal of control over the tech, libraries, or frameworks adopted. these are the biggest culprits behind crap software.
if adding a new feature or button significantly slows your app, and you had a role in the architecture, you have no one to blame but yourself
> "We spent x weeks working so users with low memory space can update"
But it's the other way around! That's the whole point. Every app starts out small. Apps don't grow unless you add complexity to them. It's much less work to do something simple than doing it overly complex. We see this all the time.
The question to ask should instead be: How can it be that "We spent x weeks working on increasing complexity" is not completely unsellable, if all your users want to do is pay their bills?
Now, reality is never that simple and users constantly ask for new features, that much is true. But why can we as an industry never listen to all those users who don't want new features?
It used to be completely normal to identify a need, sketch out the most appropriate funcitonality to solve that need, and them implement it. Then the core functionality is done. The software can continue to be developed around that functionality, but the core is fixed because the problem domain is well described.
No software is allowed to fit the problem domain anymore. It's just a constant pile of features upon features, to keep a legion of product designers, user experience managers, product owners, and an army of developers busy every day with no end in sight. The only break from the treadmill is the occasional product redesign, and if you can't afford that this increment then you can always change the frontend framework. Whatever happened to decent problem modelling and when you're done, you're done? Optimizing what we got instead of expanding it?
To an extent, I think this is still on the dev. Don't declare your feature done when the bare minimum of works on my machine when I squint is done. One of my first managers taught me this lesson, the feature isn't done when you're done coding, it's done when you've jumped through all the other hoops too, and it's actually live and ready to use. That includes stuff like tests, review, qa, and in this context, making sure it's performant. Agreeing to cut corners to meet an unrealistic deadline very much is on the dev.
Watch a Dune movie some time and replace "the spice must flow" with "the features must flow".
Making money is the task at hand, and orgs make money these days by monetizing users and not treating them well. Their status as a customer is taken for granted - because where are you going to go? All the other guys are as bad or worse.
While I agree with you that a lot of sub-par technical people are relegated to the role of QA, just because you haven't seen one proper QA person in your life, doesn't mean they don't exist.
Have you ever thought to ask if the company you're working for puts their money where their mouth is, when it comes to quality? If they did, how are these people getting hired in the first place? What responsibility falls on the engineers who interviewed these folks? Does your reporting structure reward people who raise problems, or punish them? Who do your QA people report to? And please don't say the head of development, who is responsible for deliverable dates.
The best QA people I've ever known had such a good grasp on the market and customer needs that they were, in fact, product managers. Sounds like you've probably had a similar experience.
Don't throw the baby out with the bathwater. There's plenty to learn from Statistical Process Control and Deming, etc.
I've worked on more projects without a requirements specification, than with one. Without a competent PM, how will QA people even test? I guess they can intuit what the product actually needs to do, but then there's ambiguity. The reality is that someone (product) needs to document exactly what the product needs to do and how it must operate, in no uncertain terms. Even with a spec, it's often still quite ambiguous. I honestly see these problems as organizational, so when you slag on the QA folks, I get a little miffed.
I've caught plenty of bugs at review time, that could have been caught by some basic cursory testing on the developer's part. Mistakes happen. Even QA people make mistakes, we're all human after all. Does placing the blame directly on the QA people really help you? Imagine if you started asking questions about your development process, and where things could have gone wrong? The fish rots from the head, and often times bad practices are (explicitly or implicitly) rewarded by management, because they result in faster iterations, shorter delivery time, but something is definitely being lost here.
Sorry if my rant is slightly inflammatory, this is coming from a QA person who has seen a lot of these failures in practice, so I feel the need to defend the position a bit.
Author here. I did not expect to see my post on HN!
It was a rant, I was venting, it’s not supposed to be an objective statement about the state of tech. It’s shouting into the void about the things I find unfair and unbearable, I don’t think it’s a great HN material.
I made up parts of the story because it didn’t happen to me and I didn’t want to share details of somebody else’s situation.
FWIW I think it captures the sentiment many users have towards software today fairly accurately, and every software engineer who has even a modicum of pride in their trade really ought to pay attention.
One thing I'd like to point out, though, is that this kind of stuff isn't really about micro-optimizations. Most software in the "good old days" wasn't really micro-optimized either. No, what this is about is bloat. Layers upon layers of abstractions that, in most cases, amount to rearranging the pieces in the way the author deemed most aesthetically pleasing. When I look at call stacks while debugging most modern software, I can't help but feel that it spends most of its time calling functions that call functions etc, 20-30 levels deep. Most data flow isn't from component to component, but within the component between those layers. And it all adds up.
I guess “unfair and unbearable” is paying your rent at the last minute after business hours on a phone with 2012 specs. Wouldn’t want to plan ahead and pay on time or pay with a check or pay with autopay or pay with a laptop or pay with a computer at the library for free.
You say it’s not an objective statement about the state of tech and I would agree: it’s highly subjective, a literally made up story, and a dumbass opinion.
Getting a phone capable of doing an online bill pay is trivial. Literally free with a discount shit cheap phone plan.
The victim mentality will destroy you if you let it take over.
Just because the story is believable doesn’t mean that the people who are in the story are without responsibility or fault.
When you get into a lease agreement you should know how to pay going into it. If your landlord doesn’t take a form of payment you can handle you don’t sign the lease in the first place. That’s your life responsibility as a functional adult. Paying rent every month isn’t a surprise. Being low on funds isn’t an excuse and being low on funds isn’t the issue at hand.
I have had insane numbers of problems being someone who travels/moves countries a lot with banks wanting their app to 2fa before allowing transactions, the app not working, my phone dying just when I am trying to pay my bill at a restaurant and getting my card declined, my ATM card also not working and then the website locking me out and requiring me to.... use the app to generate a 2fa code... from the phone... that just died.... on and on.
I was once trying to update my address so I could get a new bank card shipped to me as the old one was expired and I had just moved. I could not update my address beforehand because... I didn't know what my new address would be until my arrival in that country and my apartment hunt was successful. Once I tried to login, I got locked out, and upon trying everything I could to remember a special recovery code that I could not find written down anywhere, I called the bank and they said they would send me a new code by mail. But I couldn't get my code by mail because... I no longer lived at the address on file. They said sure you just need to login to update your address. Which I couldn't do. But they couldn't just send a code to a new address from someone over the phone, that wasn't secure.
I forget how I got out of that one.
I've basically checked out of all this at this point. I need to get off my ass and move my money better/differently because I've started to see a day where I can't prove who I am and I live somewhere where I can't walk into a physical location to do so. It's more than a bit scary.
I read a bunch of comments defending the devs that shouldn't be blamed, but I can't stop remembering what happened to me some time ago. First time I login on an online banking service, it required a otp code sent via sms, nothing special except there was a countdown on page, and not the one for requesting a new sms, but a countdown of 30 seconds for inserting the received code. I received the code 2 minutes later. Maybe one shouldn't blame the devs but I can't think of myself in the same situation trying hard to convince the manager/designer that that was a very bad idea, how bad you should be at ux to accept to implement something like that? Having said that the article mentions and blame Javascript, like everyone's love to hate, but in the meanwhile my "performant" google app on my iphone is almost a 1gb in size
The fundamental problem here is that in any industry where the software is an add on, and not the primary product (like banking), the company isn't punished in their pocketbook for being bad at it. So they have no incentive to make it better.
This is true but it's 'truer' for some institutions than others. I deal with two banks, and the quality of the websites and services are way different. Fortunately the better one is the one with the majority of my business.
This is an HSBC problem, not a developer problem. The banks awful tech is not news. They have to pay out a lot of fines for money laundering or whatever. They offer no competitive advantage in international banking over wise, revolut, etc
When shit hits the fan, HSBC has a physical office where you can go and solve your problems. Wave some cash around, show your ID, whatever.
Good luck solving any actual problems with Revolut. Once they randomly locked my account and it was impossible to get any actual help or talk to a real person who had any insight or authority (and then it magically unlocked few days later). I will never give any bigger amount to Revolut again.
Multiple teams working on different features without communication/collaboration, leadership changes, growth hiring (brings in a lot of devs each with their own style, culture, experience or lack of), with not enough time to learn existing guidelines because they need to hit the ground running.
Did we or did we not pick a system where you spend the least you can get away with spending and charge the most you can get away with charging, and decide that system was the only possible way for everything everywhere from the utterly frivolous to the life-sustaining to run?
About once a year my bank full fills they legal obligations and asks me a bunch of questions, mostly revolving about my need for cash. One of the final questions is "Why do you need to withdraw cash?" There's a bunch of reasons listed, guesses of some lawyer or banker as to why a person might need cash, e.g. "give to my kids", "pay my friend back a loan" and then there is the "Other, please fill in the text box". That is the one I use, every time, because they do not expect my answer, even if they blood well should. Every time I answer: "Because I do not trust you to keep the payment system running 24/7/365, and again this year you have prove my scepticism correct".
We keep pushing for more and more digital, always online solutions, but I'm an SRE. I know that we can not have 100% uptime, not for anything. Yet more and more solutions are designed without that in mind. There are no backups. When the digital solution fail we are screwed, because the systems are designed backwards. The digital, online version is the add-on, not your only option.
I don't blame the developers. I blame business people, politicians and managers for releasing ill conceived systems who's flaws are obvious to any technical minded person. I blame developers for a host of different problems, mostly related to not being able to code.
I swear, it's fucking garbage collection. I had to something fairly non-trivial in Java once for a phone app in 2011 (it was a simple OCR algorithm that could read text from low-res images as long as said text was printed by a machine with a clean seriff-like font and only contained numeric digits laid out in a grid) and I remember the biggest problem was that it kept running out of memory and the only solution was to go through the program and manually null every reference the moment it was no longer needed because the GC on android back then apparently was not very good at figuring these things out itself. Which is actually a lot more complicated than deleting pointers in C++ is because there are no destructors in java.
It made a huge difference in terms of execution speed too, IDK if phones with solid-state storage use swap partitions like PCs do but that little phone was definitely struggling with something that went away when I did the one thing the garbage collector is supposed to save me from doing.
... it's not like our best and brightest devs are the ones working on web and phone apps, especially boring ones like yet-another-banking app.
But then there's the fundamental problem of management never allocating enough time for fixing things, doing them right the first time, or constraining features to result in an achievable goal especially given the resources they're usually working with.
I don't think the HSBC app added anything new of value in years. It's a banking app, once it works it's done... but they keep sending updates that apparently only change the UI.
This is a blind spot. Generally speaking the devs are comparatively well off people and they don't live paycheck-to-paycheck. So by default devs won't even conceive of the difficulties of people who are in fact living paycheck-to-paycheck and have little buffer in their bank accounts. That's the blind spot. They won't know this is a problem unless a good PM tells them about it. Ultimately it is the job of the PM to tell the devs how important (or not) it is to do these optimizations, and how important (or not) it is to test with low-end devices with little RAM or free disk space.
I am pretty well off now but I come from a pretty poor background. I used to have to drive a cheque to my landlord's office when rent was due, during university in the late 2000s
I thought a lot of my fellow devs would be from similar backgrounds, but that is not the case at all mostly. I find a lot of my coworkers come from white collar families, or relatively well off immigrant families and I am the outlier coming from a very blue collar family
It is very common for me to have a very different perspective on things than my coworkers.
Economic background shapes us so much more than people realize
Besides the fact that the story is an example, is fully made up, and you clearly didn't read the actual article: what an incredibly out of touch response.
> I don't set up standing orders, got burned once with unarranged overdraft fees, that wasn't a good month. Better to be late a day or two with rent payment.
Anyway, this same sort of nonsense could also make it very difficult to enroll in autopay, so the main points stand.
> When someone smugly says "micro-optimisations don't matter, networks are great, CPUs fast and memory plentiful", proceeds to make an app one degree more complicated than Hello World use 4 GB of RAM and drain half my battery, I'm having dark thoughts.
I don't think that's really what's happening. What i think is happening is much worse, sadly.
"developers" saying stuff like "micro-optimisations don't matter" implying there has been an understanding on what optimisation means and then a negative evaluation. which might be a defendable position.
what I observe instead is the "businessification" of the craft of software engineering and computer programming in general.
Whereas 15-20 years ago it was "cool" to ship fast software, nowadays what's "cool" is focusing on "delivering business value" which basically boils down on pushing out features, completing user stories, adopting the new hot thing (AI anyone?), taking part to the next sprint plan and then do it all over again.
As a system engineer (I don't write software for a living, i manage infrastructure) what I see in many (most?) of my colleagues is essentially getting "good enough" on the technical side (meaning, i know enough of the language/framework/runtime we use at work to shi^H^H^H deliver new features upon request) and then one gets promoted on the basis of the thing they deliver. Don't even get me started on developers being limited by their runtime: If it's not in $language it doesn't exist.
Making software fast and lean largely plays no role in somebody getting promoted. Most software engineers usually can't estimate how much memory their software will require, not even ballpark estimate.
This means that the industry is essentially "self-optimizing" for shitty software engineers.
These observation come from almost 9 years in the industry and more than one time me having to pull out a profiler in order to point developers to the part of their software is not working appropriately... Only for them to discover the concept of "software profiler".
(btw, I think there's a huge risk AI is going to make this worse)
Okay, since this is such a common HN trope to claim that modern software is bloated for no reason, I challenge you to write an SSL handshake with an acceptably modern cipher on a piece of hardware with capability in the realm of 64kb.
So we are talking about a Commodore64 securing a basic bank transaction with modern encryption protocols in a reasonable amount of time.
That’s just a gross simplification of the things modern devices need to do today.
Simple stuff like encrypted handshakes used to be a significant performance consideration, and they are now a necessity for doing basic tasks like banking.
Modern software isn’t just bloated for no good reason and it’s such a tired trope among nerdy circles.
Sure, a phone from 2012 is powerful enough to do that specific task, but I am just using encryption as a pretty good example of how at some point you just need newer hardware in order to exist in the modern device ecosystem. No efficiency of software will make a commodore64 a usable device to use SSL in 2025.
And nobody is forcing you to exist in that system anyway. You can just physically go to the bank like my parents do. You can write checks like my parents do. This whole article is about needing technology to make a last minute payment that was highly predictable and should have been planned ahead of time.
When I was younger I used to use my banking app all the time and complain when something didn't work.
Now I realize it is not THE CENTER of banking, it's just a nice to have.
Protips: You can make wires at atms, you can send your bank details and have them do a pull. You can call the payee and let them know a wire is on the way and should arrive in x business days. You'll be fine.
With such problems it is likely that the devs do care but managers and investors do not. Perhaps freedom from constant updates and bloat might become a desirable feature that commands premium pricing?
"How is 2GB not enough to send a few numbers describing the payment through the network?"
You can thank Google for this. Their V8 JavaScript engine now controls the web at the expense of RAM. It was mainly the security feature's that I found value from with V8 but the horrible development practices that followed nullified them. I don't look at Google or Big Tech with infallible admiration and I deeply regret ever doing so.
I'm not a huge fan of the "let me tell you a story - ok, that was all made up"-hook. I was interested in finding out what the root problem was but instead this was all we got:
> I made that up. Not all of it, parts of it happened. And worse stuff happens, like when I needed to pay to get my visa and the website just wouldn't work if your phone was a few years old. It likely didn't have enough RAM for it to work. How is 2GB not enough to send a few numbers describing the payment through the network?
"Worse stuff" and a vague story (no link/source/reference) about not being able to get a visa due to an old phone. A claim I have no reason to doubt exactly, except now this is the second time the article has mentioned a problem that it hasn't explained (to be fair, the first example was made up /s).
I tire of all the "javascript sucks" people and I assume this is one of them, looking for any reason to try and shit on javascript. The last line:
> It'll mostly consist of refactoring Javascript codebases with no test coverage.
It makes absolutely no sense, it doesn't flow with the rest of the paragraph, and other than a swipe a JS devs for not writing tests (? I assume that's what it's saying?) it doesn't say anything or make sense in context.
Are some JS sites bloated? Yes. Do some people force JS or SPAs in where they don't belong? Yes. But everyone who points this out [0] normally just says "It's bad, and should stop" without any plan forward or alternative that actually makes sense. "Let's all go back to SSG-only web pages, you don't need any JS" is just silly and no one can agree on the right amount between "No JS" and the (often) strawman "huge JS page that doesn't need it".
> Benchmarks and guidelines you've read probably say "if you show any text under 5 seconds on newest iPhone on 5G connection you get 100% Performance Score, blue ribbon and your parents will be finally proud of you" because otherwise the biggest websites build by The Best Engineers in the Entire World will not get anywhere close to 100%.
What's even being said here? I'm not aware of any benchmark that says first paint <5s is good. Also, right after that they say:
> THE LIMIT IS BASICALLY THE SPEED OF LIGHT, A LITERAL SPEED OF LIGHT AND YOU SAY TAKING 10 SECONDS TO DISPLAY 1000 WORDS OF TEXT AND TWO IMAGES IS SOMETHING TO BE PROUD OF?
Is it 5 seconds? Is it 10 seconds? Is it completely made up?
Lastly, back to the title:
> I can't pay rent because devs just don't care
No. Users don't care. They just don't. You are in the minority. Oh, I'm sure you might even get the majority of people to agree that they think "websites are too slow" or "bloated", you will not, however, get any of them to change their behaviors. People vote with their feet and wallets and they have near-unanimously declared they prefer bloated SPAs over alternatives. People say a lot of things, then turn around and do something different. Look no further than reddit. There is a non-SPA version of the site yet the majority of people on the web use new reddit over old reddit [1]. I'm sure if you showed some of those people old reddit they might consider switching but they aren't seeking it out.
[0] Which, this post does not even fully touch on. There are legitimate issues but this post just hand-waves its way to "JS bad mmk?".
A stirring polemic but ultimately sophomoric - made up[1] a story to valiantly declare support, for something no one doesn't support, and disdain for those who do not support it.
If you have a 2 GB phone (2018 era) and expect it to fit a multitasking OS, and every web page to work always, bless.
(how do we know "Aw, snap!" means your phone is too old and/or out of RAM and if it does, its the sites fault?)
20 years ago I had a multi-tasking OS (Windows XP) that could run 64 player 3d games[0] at 1680x1050 resolution while voice-chatting with my friends, running a chat client that integrated with games (xfire) and another client to talk to normie friends (Trillian,Gaim/Pidgin), and playing background music, all with 1 GB memory as the recommended hardware (512 MB minimum). A modern low-end phone is wildly more powerful than a mid-00s gaming PC. From what I can tell, Android can't even play two audio streams at once.
The irony is also that it would be way cheaper for people to develop websites as basic, old-school, reliable HTML pages with forms. Literal children were learning the "frontend" skills necessary to do that in the late 90s. HTML is designed to be easy to learn in a few minutes.
> The irony is also that it would be way cheaper for people to develop websites as basic, old-school, reliable HTML pages with forms. Literal children were learning the "frontend" skills necessary to do that in the late 90s. HTML is designed to be easy to learn in a few minutes.
Cheaper to develop but who are you developing for? You won't have any customers. Customers demand JS-heavy sites by virtue of the features/interactions they ask for.
Devs don't care? No, users don't care and they will not reward you for making a HTML-only form website, no matter how they have complained about sluggish/bloated websites, they will continue to use them, even with alternatives available.
As an example, I recently had to pay for parking with a website because the card reader on the machine was busted. So I scanned the QR code and loaded up the site, had to fiddle to enable some of the scripts, and make my payment. After I was done, I saw it had used over 25 MB--4% of my data for the month--to collect roughly 30 bytes of information from me, assuming a naive encoding (16 digit CC, 3 digit CV2, 8 digit license plate #, 2 digit state). Maybe it also needed the billing address, so another 30 bytes or whatever. Point is the TLS handshake should've been 95% of the traffic.
If anything, I almost left to go look elsewhere because it was too much of a pain to get it to work on my phone and I didn't want to use up all of my data fiddling with it. No one is demanding a JS heavy site here. Customers are not demanding anything. It's a near certainty that no one has ever provided feedback to the parking lot owner about their payment form. I did actually leave digikey's store because I literally could not figure out how to get their payment form to work without blanket enabling all scripts (and they have a ton of third-party tracking scripts).
Sites that are for services that actually matter (e.g. banks, governments, utilities) also don't need to be flashy. You don't need to sell me on filing for my paternity leave or filing taxes or making a bank transfer or paying a bill. Just present the form. The absolute ideal website in such cases is a transcription of the paper form it replaces with a tiny bit of javascript to check constraints/field validation. The free tax filing website for the US is a decent inspiration for this: from a UX perspective it's just electronic versions of the paper forms with some ability to auto-calculate some fields.
> From what I can tell, Android can't even play two audio streams at once.
This is purely design-decision-based, it has nothing to do with the limitations of the hardware. A laptop with a weaker CPU than a flagship Android could probably stream and play hundreds of audio streams (no promise it'll sound coherent, though).
I'm 37, QBasic since 7, built my first Linux box at 12. (25 years ago. My god)
I have learned to appreciate, and let slide, a good hand-wavy "get off my lawn" formatted anecdote to relate history...if it owns it and isn't slippery in the process.
Here, we're sort of waving at "if websites weren't in JS, the imaginary phone would have loaded the imaginary page instead of saying "oh snap", which clearly indicated it was out of RAM"
Some errata:
Android can play more than 2 media streams at once.
A 2GB phone isn't a modern phone. I worked on Android and that was our Emerging Markets™ standard (read: dirt cheapest phone expected to work ok) in 2018, 7 years ago.
> Android can play more than 2 media streams at once.
From what I can glean that's only if the apps allow that, by not requesting the audio focus, and the documentation recommends to request it.
It's indeed very rare to find two (or more) apps that can play audio at the same time.
Not to mention that you can't set the volume of the individual apps (unless they have their own volume controls).
> A 2GB phone isn't a modern phone. I worked on Android and that was our Emerging Markets™ standard (read: dirt cheapest phone expected to work ok) in 2018, 7 years ago.
He might have meant 2GB of free ram, and so at least a 4GB phone.
>When someone smugly says "micro-optimisations don't matter, networks are great, CPUs fast and memory plentiful", proceeds to make an app one degree more complicated than Hello World use 4 GB of RAM and drain half my battery, I'm having dark thoughts.
TBH I don't think those are the same person. Lots of apps glued together by developers who never think about micro-optimizations, maybe under severe time crunches without QA teams or PMs who don't care and managers who chose to go with the lowest bidder, but sure, let's blame the developer.
I look at video game forums and subreddits and see the same logic when they don't like something; like, you honestly don't know how software or games are built if you are solely blaming the devs at this point.
> I look at video game forums and subreddits and see the same logic when they don't like something; like, you honestly don't know how software or games are built if you are solely blaming the devs at this point.
I always read "devs" in video game discussions as referring to the company which owns the development work rather than the programmers at the company. If someone wrote a comment, "The devs don't let their programmers do their job" on a video game forum, I would logically expand "devs" to "managers at the development company". I totally see how that's not intuitive to a developer, though; perhaps that comes from my interest in video games before I ever became a programmer.
In many cases, micro-optimisations don’t matter. If they did, we wouldn’t have shell scripts.
It is a bit sad that a modern processor could run CP/M like a 4GHz Z80, but I also remember that back then Unix could take many minutes to come up.
Do you mean 4MHz Z80?
it's the ones who rave "microoptimizations matter goddamn it!" who will try to shave 150ms off the "send money" screen of the banking app and not notice that the app takes up 750MB of storage.
Or spend 2 days shaving off 150ms that no one asked for when we have much more pressing features. I don't care if the button is faster if the action it kicks off doesn't work. The road to hell and all of that...
One of those matters a lot more to most users
It's kind of funny because I'm not 100% sure which one you are talking about. I assume it's the time, storage be damned. I agree that's probably what users will say but in that world (picking speed over storage) we will see this exact same article posted with a stronger focus on the app size (the post does make at least 1 mention of app size).
But it's usually the other way around? Lightweight usually means faster. It's takes less bandwidth, it can be cached more efficiently at network edges and in CPU cache.
There exist tradeoffs that might make bulkier applications worth it, like faster and cheaper development I guess.
...or maybe the ones who have the ability to shave 150ms off the "send money" screen do not have the authority to affect how big the app is overall.
Add in the issue of change for the sake of change. I'm older, and wear hearing aids. Today, there was an app update that added nothing new, but it did rearrange the GUI. It's not better, it's just different.
Being a techie, it's no problem for me. But: how many nontechnical, elderly people are going to be lost?
Stupid management? New UI designer wanting to prove themselves? Don't know, don't care - I played dumb and sent in a confused complaint.
I absolutely hate pointless UI changes.
Even worse ab tests. Had Gmail once on 4 different devices all going through different ab tests I couldn't make sense of it.
A UI change in my Tesla pushed me over the edge and made me commit to selling it back in December 2020.
>New UI designer wanting to prove themselves?
it's actually kind of comical to think of all the IT departments out there forcing the entire company to beta-test a new webapp every five-years solely because they're either bored or afraid of not looking busy. I would rather they just spend 90% of their work-week playing WoW and only show up when there's a new problem but i can also understand the pressure to look busy and not let some overpaid exec like elon musk see how not-busy they are and come up with the bright idea that since the computers work 90% of the time without manual intervention that means you only need 10% of your staff.
My US bank is hilariously slow to change and I love it, debit card doesn't have that wireless thingy, the website did change recently, but it had 2000s dot com boom vibes before, and a rate of change of once every 20 years is fine, especially since they sent copious amount of emails and followed up to make sure everyone was able to do stuff.
In general I think the US is very respectful of slow change, hell you file taxes by sending mail or faxes!
I do find it ridiculous just how big mobile applications have gotten. Why does the UPS app have to be over 100 MB? It's got maybe a couple dozen unique screens visible to the user, few image assets, and mostly just settings, and account login, text entry, and pulling results from the web. It's not unique to UPS, most of the apps on my phone are of that size magnitude (Amazon is almost a quarter gigabyte with data), it was just a convenient choice because of how simple the app seems.
That being said, the oddest-to-me thing in this article is a bank call center not being open 24/7.
I don't know about iOS, but when I look at big APKs on Android, what I usually see is a good number of images that are essentially repeated 3-4 times for different dpi ranges, and localized text, in utf-16, for many languages, uncompressed. I think I saw something recently about Google providing tools to compressing localized text, but I may be misremembering. The logic for storing localized text uncompressed is something about mmaping the data and accessing by offset for efficiency, but when an app supports a majority of the world's living written languages, and users tend to support only one or two, the storage cost doesn't make sense. At one point, Google Play tried to do localization packs, but it never actually made sense to use, so nobody does. I know proprietary options exist to compress localized text in apks, but being part of the default system is important.
</dated rant> (edit: my information is old, and perhaps hopefully outdated)
Android as a platform definitely supports only downloading the image assets etc relevant for your specific device - whether applications are taking advantage of this is a different question https://developer.android.com/guide/app-bundle/app-bundle-fo...
Uhm I think Google Play now always only sends you only the resources for your device and language? (except for the few old apps that are exempt from giving the signing key to Google)
>> Why does the UPS app have to be over 100 MB?
Oh oh!! Let me guess!! I don't do mobile but have looked into it. And the guy behind me is doing an app too. Everyone wants to minimize development effort so they pick a framework that will spit out both iOS and Android apps. It's the framework that ends up bloating everything. Maybe? That doesn't explain "why", it just pushes it off the app developer onto someone else.
It seems always so weird, when you compare those to some older well optimized desktop softwares. Some with decent number of features being in under 10 megabyte range...
>Why does the UPS app have to be over 100 MB?
There are two conflicting problems here that are the two heads of the same coin:
>"Why is this app so big, don't the devs respect my storage?"
vs:
>"Why is this app so slow, don't the devs respect people with poor connections?"
I don't expect it to fetch everything from a server every time, not every app needs to be only a browser serving remote content. I just expect a simple app to be simple in size, there just isn't much going on in this app.
? They're not in conflict at all, if the app is smaller it's also faster to download.
The app is only downloaded once every month or two for the usual updates. It happens in the background when you aren't using your phone anyway, and by default both OSes will wait until you're on wifi too.
App size doesn't matter much in the actual use of the app, especially if you're using it often.
... except that the complete collection of everything the UPS app needs to execute or display, in order to actually fulfill its function, summed up throughout all of its operation in every possible mode, probably fits in 1MB. If there's 100MB of stuff you store or potentially download for a shipping app, then you're including something that doesn't add value for the user.
Start by removing all the pictures, videos, and similar. Then take out the analytics crap. Then, if your app is still big, figure out what's wrong with your code.
> Why does the UPS app have to be over 100 MB?
The same reason it takes longer to write a shorter letter. Nothing is free, removing things costs time.
My experience is that it doesn't take longer. It just takes knowing that a lot of "best practices" are actually not (both dev and management need to know this, or at least management needs to trust dev).
Apps are like subscriptions, a way to get their claws into your stuff and continually drain whatever they can from you.
Is 100MB a lot? It feels like a decent size, yet if you consider that a hello world weighs 17kb, it feels like a lot without an explanation.
I'd venture a guess that there's a fat dependency chain based on the need to avoid reinventing the wheel all the while not paying for software dependencies.
NPM import npm2 npm2 install obscuredependency
And npm2 doing full dependency duplication to avoid version conflicts, leaving like 2 or 3 versions of each base library, that kind of stuff
100 MB is a lot for a simple application. On the Android phone I had in the mid-2010s, that would have taken up a ridiculous amount of my precious little storage.
That chain of dependencies does fall in line with the message (regardless of how widely it applies) of "modern developers don't care about efficiency".
In my experience a lot of these kinds of messed up priorities tend to come from managers and PMs, not engineers. A lot of engineers would find it a fun challenge to support old devices and optimize the hell out of your app, but they just aren't given the opportunity.
Right on the money. We get paid to add more pretty buttons, rather than make sure exceptions risen by existing buttons are handled gracefuly at no cost to UX.
> I made that up. Not all of it, parts of it happened.
> I'm just ranting because it makes my blood boil.
So now we are just making up hypothetical scenarios and getting mad over them?
Tech people really need more hobbies.
Use cases are hypothetical scenarios worth getting mad over. They are THE things we should give a shit about. When somebody on my team suggests something that's user-hostile in 1% of cases because they don't give a shit, I'm not going to just say, "well, I better not have negative emotions". That's how we get the garbage world.
But the hypothetical part here isn't just the use case. It's also the outcome. And the bad outcome did not happen, the author made it up.
If you want to do a good job, definitely do not get mad over use cases.
Devs are more like Spock, not The Hulk.
We work better when we stay cool, clam, and logical, not when we get angry and heated.
Repetitive focus on negative thoughts or hypothetical situations could be a symptom of anxiety or anger. Doesn’t have anything to do with tech in my experience, more with mental health in general.
Yeah, I was angry when I was writing it, not denying it.
Anger is often the only way to motivate action, since when you were calm you didn't care about solving it.
I have definitely been in dozens upon dozens upon dozens of situations where a website or app struggled to do something that my dad's PC in the 90s could do fast enough for the modem to be the only bottleneck. And even then the P1 with the modem that ran into the phone line probably still wins out, which is disgusting given that its entire disk was smaller than the RAM on my phone.
ROPs vulernabilities and lack of linux compatibility notwithstanding, i swear flash wasn't even half as bad as modern web crap.
It's a very sophisticated rhetorical technique called "attacking a strawman." They've already won all the normal arguments they could find, so they create a strawman and attack it.
There is one way to pay rent which requires no RAM or CPU cycles: write a check, and mail it. In my experience, most payees accept the date a check is mailed as the date of payment. (There may be exceptions to this, and I'm not sure what, if any, protections the law provides, so it may not be a valid fallback.)
In general society needs to maintain these low-tech fallbacks to high-tech "improvements". For example, we should keep taxis (that can be flagged down with your hand, and paid for in cash) and not rely solely on Uber, Lyft, etc. We should keep the ability to order from a human at restaurants. We must resist putting the smartphone into the unreplacable critical path of human life. To do so values technology above the value of human life.
It's already happening today where children and the elderly need a fully-charged, fully-patched secure device with multiple apps, passwords and two-factor authentication, just to receive health care.
For this to work, cash needs to suck less. The convenience factor will overpower any concerns you or i have.
How would cash be made to "suck less"?
I think coins need to be banned full stop. At current prices, you can probably just do a paper quarter and create a law to allow cash payments to be rounded down to the nearest quarter. Most business would be ok with this since they can avoid the credit card fees. I think we should also go plastic like canada, the bills are easier to count, harder to get dirty, and harder to get lost or crumpled. I'd also imagine itd also be harder to counterfeit and easier to track.
In general one should never agree to use an app to pay rent, since these apps are often wrapped in terms and conditions. You should always just pay your rent by check, cash, or money order. Every jurisdiction in America requires lessors to accept these.
Not quite. According to a quick search [1]: "Under California law, it's illegal for a landlord to require cash and/or electronic deposits as the sole methods to pay rent.1 Landlords must allow a tenant to pay rent using at least one of these other options as well: check, cashier's check, or money order."
When I lived in CA I had a landlord that demanded cashier's check. Do you know how annoying those are to get?
I could have also paid cash but then I'd take the risk that the cash, dropped in a mailbox, would "go missing".
[1] https://caretaker.com/learn/rent/rent-payment-laws-in-califo...
Doesn't seem like that much of a problem? My bank has a form in their app to have a cashier's check mailed to whomever.
My experience as a dev is that it's not devs not wanting to fix those issues it's decision makers that can't sell it upwards.
"We spent x weeks working so users with low memory space can update" is like unsellable and will get you laughs as a response.
On top of that, reality is that this effort is rarely deemed worth it in money terms. How many users are gonna change bank for that?
And don't get me started on QA.
Software is complicated and it's good and complex as the organizations making it, we devs are just one part of the problem.
most devs complain about management tying their hands but more often than not they have a great deal of control over the tech, libraries, or frameworks adopted. these are the biggest culprits behind crap software.
if adding a new feature or button significantly slows your app, and you had a role in the architecture, you have no one to blame but yourself
> "We spent x weeks working so users with low memory space can update"
But it's the other way around! That's the whole point. Every app starts out small. Apps don't grow unless you add complexity to them. It's much less work to do something simple than doing it overly complex. We see this all the time.
The question to ask should instead be: How can it be that "We spent x weeks working on increasing complexity" is not completely unsellable, if all your users want to do is pay their bills?
Now, reality is never that simple and users constantly ask for new features, that much is true. But why can we as an industry never listen to all those users who don't want new features?
It used to be completely normal to identify a need, sketch out the most appropriate funcitonality to solve that need, and them implement it. Then the core functionality is done. The software can continue to be developed around that functionality, but the core is fixed because the problem domain is well described.
No software is allowed to fit the problem domain anymore. It's just a constant pile of features upon features, to keep a legion of product designers, user experience managers, product owners, and an army of developers busy every day with no end in sight. The only break from the treadmill is the occasional product redesign, and if you can't afford that this increment then you can always change the frontend framework. Whatever happened to decent problem modelling and when you're done, you're done? Optimizing what we got instead of expanding it?
To an extent, I think this is still on the dev. Don't declare your feature done when the bare minimum of works on my machine when I squint is done. One of my first managers taught me this lesson, the feature isn't done when you're done coding, it's done when you've jumped through all the other hoops too, and it's actually live and ready to use. That includes stuff like tests, review, qa, and in this context, making sure it's performant. Agreeing to cut corners to meet an unrealistic deadline very much is on the dev.
I agree 100% as I wrote in my final sentence, we're just part of the picture.
Watch a Dune movie some time and replace "the spice must flow" with "the features must flow".
Making money is the task at hand, and orgs make money these days by monetizing users and not treating them well. Their status as a customer is taken for granted - because where are you going to go? All the other guys are as bad or worse.
The Chase app I use is 298mb.
While I agree with you that a lot of sub-par technical people are relegated to the role of QA, just because you haven't seen one proper QA person in your life, doesn't mean they don't exist.
Have you ever thought to ask if the company you're working for puts their money where their mouth is, when it comes to quality? If they did, how are these people getting hired in the first place? What responsibility falls on the engineers who interviewed these folks? Does your reporting structure reward people who raise problems, or punish them? Who do your QA people report to? And please don't say the head of development, who is responsible for deliverable dates.
The best QA people I've ever known had such a good grasp on the market and customer needs that they were, in fact, product managers. Sounds like you've probably had a similar experience.
Don't throw the baby out with the bathwater. There's plenty to learn from Statistical Process Control and Deming, etc.
I've worked on more projects without a requirements specification, than with one. Without a competent PM, how will QA people even test? I guess they can intuit what the product actually needs to do, but then there's ambiguity. The reality is that someone (product) needs to document exactly what the product needs to do and how it must operate, in no uncertain terms. Even with a spec, it's often still quite ambiguous. I honestly see these problems as organizational, so when you slag on the QA folks, I get a little miffed.
I've caught plenty of bugs at review time, that could have been caught by some basic cursory testing on the developer's part. Mistakes happen. Even QA people make mistakes, we're all human after all. Does placing the blame directly on the QA people really help you? Imagine if you started asking questions about your development process, and where things could have gone wrong? The fish rots from the head, and often times bad practices are (explicitly or implicitly) rewarded by management, because they result in faster iterations, shorter delivery time, but something is definitely being lost here.
Sorry if my rant is slightly inflammatory, this is coming from a QA person who has seen a lot of these failures in practice, so I feel the need to defend the position a bit.
Author here. I did not expect to see my post on HN!
It was a rant, I was venting, it’s not supposed to be an objective statement about the state of tech. It’s shouting into the void about the things I find unfair and unbearable, I don’t think it’s a great HN material.
I made up parts of the story because it didn’t happen to me and I didn’t want to share details of somebody else’s situation.
FWIW I think it captures the sentiment many users have towards software today fairly accurately, and every software engineer who has even a modicum of pride in their trade really ought to pay attention.
One thing I'd like to point out, though, is that this kind of stuff isn't really about micro-optimizations. Most software in the "good old days" wasn't really micro-optimized either. No, what this is about is bloat. Layers upon layers of abstractions that, in most cases, amount to rearranging the pieces in the way the author deemed most aesthetically pleasing. When I look at call stacks while debugging most modern software, I can't help but feel that it spends most of its time calling functions that call functions etc, 20-30 levels deep. Most data flow isn't from component to component, but within the component between those layers. And it all adds up.
Well, it actually did happen to me (precisely to pay the rent), and I burst into applause after reading your blog post
It really makes me happy to know that my writing struck a chord for at least one person - thank you!
I guess “unfair and unbearable” is paying your rent at the last minute after business hours on a phone with 2012 specs. Wouldn’t want to plan ahead and pay on time or pay with a check or pay with autopay or pay with a laptop or pay with a computer at the library for free.
You say it’s not an objective statement about the state of tech and I would agree: it’s highly subjective, a literally made up story, and a dumbass opinion.
Getting a phone capable of doing an online bill pay is trivial. Literally free with a discount shit cheap phone plan.
The victim mentality will destroy you if you let it take over.
> Getting a phone capable of doing an online bill pay is trivial. Literally free with a discount shit cheap phone plan.
No matter how cheap your phone is, if you're poor someone will always judge you because your phone is too expensive.
"Why do you have a more recent phone that 2012 if you're on benefits?"
I don’t think this has been true in the last 5-8 years where phones are incrementally different and essentially look identical.
I saw an ad yesterday for a free iPhone 13 with a discount carrier and that phone is almost indistinguishable from the current iPhone on sale.
The thing is, until he said it was a made-up story, I thought it was real. This shows that things like that started to become the real norm.
I also don't think the author is in a victim mentality, it is more like a reminder to other developers that they can do so much better.
Just because the story is believable doesn’t mean that the people who are in the story are without responsibility or fault.
When you get into a lease agreement you should know how to pay going into it. If your landlord doesn’t take a form of payment you can handle you don’t sign the lease in the first place. That’s your life responsibility as a functional adult. Paying rent every month isn’t a surprise. Being low on funds isn’t an excuse and being low on funds isn’t the issue at hand.
I have had insane numbers of problems being someone who travels/moves countries a lot with banks wanting their app to 2fa before allowing transactions, the app not working, my phone dying just when I am trying to pay my bill at a restaurant and getting my card declined, my ATM card also not working and then the website locking me out and requiring me to.... use the app to generate a 2fa code... from the phone... that just died.... on and on.
I was once trying to update my address so I could get a new bank card shipped to me as the old one was expired and I had just moved. I could not update my address beforehand because... I didn't know what my new address would be until my arrival in that country and my apartment hunt was successful. Once I tried to login, I got locked out, and upon trying everything I could to remember a special recovery code that I could not find written down anywhere, I called the bank and they said they would send me a new code by mail. But I couldn't get my code by mail because... I no longer lived at the address on file. They said sure you just need to login to update your address. Which I couldn't do. But they couldn't just send a code to a new address from someone over the phone, that wasn't secure.
I forget how I got out of that one.
I've basically checked out of all this at this point. I need to get off my ass and move my money better/differently because I've started to see a day where I can't prove who I am and I live somewhere where I can't walk into a physical location to do so. It's more than a bit scary.
If you're in the critical path for life, all functionality should be accessible for someone accessing the internet in a library.
How about if no technology is required at all to receive services related to the "critical path for life".
I read a bunch of comments defending the devs that shouldn't be blamed, but I can't stop remembering what happened to me some time ago. First time I login on an online banking service, it required a otp code sent via sms, nothing special except there was a countdown on page, and not the one for requesting a new sms, but a countdown of 30 seconds for inserting the received code. I received the code 2 minutes later. Maybe one shouldn't blame the devs but I can't think of myself in the same situation trying hard to convince the manager/designer that that was a very bad idea, how bad you should be at ux to accept to implement something like that? Having said that the article mentions and blame Javascript, like everyone's love to hate, but in the meanwhile my "performant" google app on my iphone is almost a 1gb in size
One of the reasons I have refused to switch to HSBC's app is because I refuse to take up space on my devices with software that shouldn't exist.
I remember when HSBC had a website which did not require JS to use it.
Dark thoughts indeed.
The fundamental problem here is that in any industry where the software is an add on, and not the primary product (like banking), the company isn't punished in their pocketbook for being bad at it. So they have no incentive to make it better.
They know you'll come back regardless.
This is true but it's 'truer' for some institutions than others. I deal with two banks, and the quality of the websites and services are way different. Fortunately the better one is the one with the majority of my business.
They're not punished enough. I actually just left my bank over their app and web app.
Google's stock apps have been steadily growing in size as well
This is an HSBC problem, not a developer problem. The banks awful tech is not news. They have to pay out a lot of fines for money laundering or whatever. They offer no competitive advantage in international banking over wise, revolut, etc
Poorly made and performing websites are everywhere. Just ask my wife how often I rant about it.
When shit hits the fan, HSBC has a physical office where you can go and solve your problems. Wave some cash around, show your ID, whatever.
Good luck solving any actual problems with Revolut. Once they randomly locked my account and it was impossible to get any actual help or talk to a real person who had any insight or authority (and then it magically unlocked few days later). I will never give any bigger amount to Revolut again.
They made up the story
Multiple teams working on different features without communication/collaboration, leadership changes, growth hiring (brings in a lot of devs each with their own style, culture, experience or lack of), with not enough time to learn existing guidelines because they need to hit the ground running.
The solution to all of these is: slow down.
Did we or did we not pick a system where you spend the least you can get away with spending and charge the most you can get away with charging, and decide that system was the only possible way for everything everywhere from the utterly frivolous to the life-sustaining to run?
Developers do care. The author should bark at the people who pay developers to prioritize other tasks.
Let's not pretend that all developers care, please.
I'm far from sure that the majority cares, either.
About once a year my bank full fills they legal obligations and asks me a bunch of questions, mostly revolving about my need for cash. One of the final questions is "Why do you need to withdraw cash?" There's a bunch of reasons listed, guesses of some lawyer or banker as to why a person might need cash, e.g. "give to my kids", "pay my friend back a loan" and then there is the "Other, please fill in the text box". That is the one I use, every time, because they do not expect my answer, even if they blood well should. Every time I answer: "Because I do not trust you to keep the payment system running 24/7/365, and again this year you have prove my scepticism correct".
We keep pushing for more and more digital, always online solutions, but I'm an SRE. I know that we can not have 100% uptime, not for anything. Yet more and more solutions are designed without that in mind. There are no backups. When the digital solution fail we are screwed, because the systems are designed backwards. The digital, online version is the add-on, not your only option.
I don't blame the developers. I blame business people, politicians and managers for releasing ill conceived systems who's flaws are obvious to any technical minded person. I blame developers for a host of different problems, mostly related to not being able to code.
I swear, it's fucking garbage collection. I had to something fairly non-trivial in Java once for a phone app in 2011 (it was a simple OCR algorithm that could read text from low-res images as long as said text was printed by a machine with a clean seriff-like font and only contained numeric digits laid out in a grid) and I remember the biggest problem was that it kept running out of memory and the only solution was to go through the program and manually null every reference the moment it was no longer needed because the GC on android back then apparently was not very good at figuring these things out itself. Which is actually a lot more complicated than deleting pointers in C++ is because there are no destructors in java.
It made a huge difference in terms of execution speed too, IDK if phones with solid-state storage use swap partitions like PCs do but that little phone was definitely struggling with something that went away when I did the one thing the garbage collector is supposed to save me from doing.
I don't expect this to go over well but...
... it's not like our best and brightest devs are the ones working on web and phone apps, especially boring ones like yet-another-banking app.
But then there's the fundamental problem of management never allocating enough time for fixing things, doing them right the first time, or constraining features to result in an achievable goal especially given the resources they're usually working with.
I don't think the HSBC app added anything new of value in years. It's a banking app, once it works it's done... but they keep sending updates that apparently only change the UI.
Sounds like all of this could be solved by not manually paying your rent at the last minute?
This is a blind spot. Generally speaking the devs are comparatively well off people and they don't live paycheck-to-paycheck. So by default devs won't even conceive of the difficulties of people who are in fact living paycheck-to-paycheck and have little buffer in their bank accounts. That's the blind spot. They won't know this is a problem unless a good PM tells them about it. Ultimately it is the job of the PM to tell the devs how important (or not) it is to do these optimizations, and how important (or not) it is to test with low-end devices with little RAM or free disk space.
This is something I struggle with a bit as a dev
I am pretty well off now but I come from a pretty poor background. I used to have to drive a cheque to my landlord's office when rent was due, during university in the late 2000s
I thought a lot of my fellow devs would be from similar backgrounds, but that is not the case at all mostly. I find a lot of my coworkers come from white collar families, or relatively well off immigrant families and I am the outlier coming from a very blue collar family
It is very common for me to have a very different perspective on things than my coworkers.
Economic background shapes us so much more than people realize
First sentence in that (made up) story:
>Rent's due today, thank heavens I just got paid.
I assume the "last minute" wasn't entirely their choice.
Besides the fact that the story is an example, is fully made up, and you clearly didn't read the actual article: what an incredibly out of touch response.
This is hideous.
> I don't set up standing orders, got burned once with unarranged overdraft fees, that wasn't a good month. Better to be late a day or two with rent payment.
Anyway, this same sort of nonsense could also make it very difficult to enroll in autopay, so the main points stand.
They made up the story
Doesn't matter if the story is made up or not. It's a believable story so we should treat it as if it's real.
A lot of people live paycheck to paycheck. They can't afford to pay rent before they get paid.
> When someone smugly says "micro-optimisations don't matter, networks are great, CPUs fast and memory plentiful", proceeds to make an app one degree more complicated than Hello World use 4 GB of RAM and drain half my battery, I'm having dark thoughts.
I don't think that's really what's happening. What i think is happening is much worse, sadly.
"developers" saying stuff like "micro-optimisations don't matter" implying there has been an understanding on what optimisation means and then a negative evaluation. which might be a defendable position.
what I observe instead is the "businessification" of the craft of software engineering and computer programming in general.
Whereas 15-20 years ago it was "cool" to ship fast software, nowadays what's "cool" is focusing on "delivering business value" which basically boils down on pushing out features, completing user stories, adopting the new hot thing (AI anyone?), taking part to the next sprint plan and then do it all over again.
As a system engineer (I don't write software for a living, i manage infrastructure) what I see in many (most?) of my colleagues is essentially getting "good enough" on the technical side (meaning, i know enough of the language/framework/runtime we use at work to shi^H^H^H deliver new features upon request) and then one gets promoted on the basis of the thing they deliver. Don't even get me started on developers being limited by their runtime: If it's not in $language it doesn't exist.
Making software fast and lean largely plays no role in somebody getting promoted. Most software engineers usually can't estimate how much memory their software will require, not even ballpark estimate.
This means that the industry is essentially "self-optimizing" for shitty software engineers.
These observation come from almost 9 years in the industry and more than one time me having to pull out a profiler in order to point developers to the part of their software is not working appropriately... Only for them to discover the concept of "software profiler".
(btw, I think there's a huge risk AI is going to make this worse)
you just had a taste of the ordinary tyranny.
> It likely didn't have enough RAM for it to work. How is 2GB not enough to send a few numbers describing the payment through the network?
OP is using a potato with the same amount of RAM as a smartphone from 2012 and is complaining about performance issues.
You pay your rent. Send a check. Pay it when the call center is open and don’t wait until the last minute.
Don’t blame your phone or the technological progress of modern software.
Not being able to do a 64kB task with 2GB of memory is "technological progress" how, exactly?
Okay, since this is such a common HN trope to claim that modern software is bloated for no reason, I challenge you to write an SSL handshake with an acceptably modern cipher on a piece of hardware with capability in the realm of 64kb.
So we are talking about a Commodore64 securing a basic bank transaction with modern encryption protocols in a reasonable amount of time.
There is almost nothing my current phone can do that a phone from 2012 couldn't do, it's just the one from 2012 can't run today's bloated software.
That’s just a gross simplification of the things modern devices need to do today.
Simple stuff like encrypted handshakes used to be a significant performance consideration, and they are now a necessity for doing basic tasks like banking.
Modern software isn’t just bloated for no good reason and it’s such a tired trope among nerdy circles.
Sure, a phone from 2012 is powerful enough to do that specific task, but I am just using encryption as a pretty good example of how at some point you just need newer hardware in order to exist in the modern device ecosystem. No efficiency of software will make a commodore64 a usable device to use SSL in 2025.
And nobody is forcing you to exist in that system anyway. You can just physically go to the bank like my parents do. You can write checks like my parents do. This whole article is about needing technology to make a last minute payment that was highly predictable and should have been planned ahead of time.
He probably meant free ram
And it wouldn't be a potato were it not for the operating system and the apps' increased usage
Can't you use a Debit Card?
When I was younger I used to use my banking app all the time and complain when something didn't work.
Now I realize it is not THE CENTER of banking, it's just a nice to have.
Protips: You can make wires at atms, you can send your bank details and have them do a pull. You can call the payee and let them know a wire is on the way and should arrive in x business days. You'll be fine.
With such problems it is likely that the devs do care but managers and investors do not. Perhaps freedom from constant updates and bloat might become a desirable feature that commands premium pricing?
"i made that up"
...so they can have a clickbaity title. Guess what - writers just don't care either
"How is 2GB not enough to send a few numbers describing the payment through the network?"
You can thank Google for this. Their V8 JavaScript engine now controls the web at the expense of RAM. It was mainly the security feature's that I found value from with V8 but the horrible development practices that followed nullified them. I don't look at Google or Big Tech with infallible admiration and I deeply regret ever doing so.
I'm not a huge fan of the "let me tell you a story - ok, that was all made up"-hook. I was interested in finding out what the root problem was but instead this was all we got:
> I made that up. Not all of it, parts of it happened. And worse stuff happens, like when I needed to pay to get my visa and the website just wouldn't work if your phone was a few years old. It likely didn't have enough RAM for it to work. How is 2GB not enough to send a few numbers describing the payment through the network?
"Worse stuff" and a vague story (no link/source/reference) about not being able to get a visa due to an old phone. A claim I have no reason to doubt exactly, except now this is the second time the article has mentioned a problem that it hasn't explained (to be fair, the first example was made up /s).
I tire of all the "javascript sucks" people and I assume this is one of them, looking for any reason to try and shit on javascript. The last line:
> It'll mostly consist of refactoring Javascript codebases with no test coverage.
It makes absolutely no sense, it doesn't flow with the rest of the paragraph, and other than a swipe a JS devs for not writing tests (? I assume that's what it's saying?) it doesn't say anything or make sense in context.
Are some JS sites bloated? Yes. Do some people force JS or SPAs in where they don't belong? Yes. But everyone who points this out [0] normally just says "It's bad, and should stop" without any plan forward or alternative that actually makes sense. "Let's all go back to SSG-only web pages, you don't need any JS" is just silly and no one can agree on the right amount between "No JS" and the (often) strawman "huge JS page that doesn't need it".
> Benchmarks and guidelines you've read probably say "if you show any text under 5 seconds on newest iPhone on 5G connection you get 100% Performance Score, blue ribbon and your parents will be finally proud of you" because otherwise the biggest websites build by The Best Engineers in the Entire World will not get anywhere close to 100%.
What's even being said here? I'm not aware of any benchmark that says first paint <5s is good. Also, right after that they say:
> THE LIMIT IS BASICALLY THE SPEED OF LIGHT, A LITERAL SPEED OF LIGHT AND YOU SAY TAKING 10 SECONDS TO DISPLAY 1000 WORDS OF TEXT AND TWO IMAGES IS SOMETHING TO BE PROUD OF?
Is it 5 seconds? Is it 10 seconds? Is it completely made up?
Lastly, back to the title:
> I can't pay rent because devs just don't care
No. Users don't care. They just don't. You are in the minority. Oh, I'm sure you might even get the majority of people to agree that they think "websites are too slow" or "bloated", you will not, however, get any of them to change their behaviors. People vote with their feet and wallets and they have near-unanimously declared they prefer bloated SPAs over alternatives. People say a lot of things, then turn around and do something different. Look no further than reddit. There is a non-SPA version of the site yet the majority of people on the web use new reddit over old reddit [1]. I'm sure if you showed some of those people old reddit they might consider switching but they aren't seeking it out.
[0] Which, this post does not even fully touch on. There are legitimate issues but this post just hand-waves its way to "JS bad mmk?".
[1] https://www.reddit.com/r/TheoryOfReddit/comments/zvbm6q/what...
Works on my phone /s
A stirring polemic but ultimately sophomoric - made up[1] a story to valiantly declare support, for something no one doesn't support, and disdain for those who do not support it.
If you have a 2 GB phone (2018 era) and expect it to fit a multitasking OS, and every web page to work always, bless.
(how do we know "Aw, snap!" means your phone is too old and/or out of RAM and if it does, its the sites fault?)
[1] "I made that up.", beginning of ¶2
20 years ago I had a multi-tasking OS (Windows XP) that could run 64 player 3d games[0] at 1680x1050 resolution while voice-chatting with my friends, running a chat client that integrated with games (xfire) and another client to talk to normie friends (Trillian,Gaim/Pidgin), and playing background music, all with 1 GB memory as the recommended hardware (512 MB minimum). A modern low-end phone is wildly more powerful than a mid-00s gaming PC. From what I can tell, Android can't even play two audio streams at once.
The irony is also that it would be way cheaper for people to develop websites as basic, old-school, reliable HTML pages with forms. Literal children were learning the "frontend" skills necessary to do that in the late 90s. HTML is designed to be easy to learn in a few minutes.
[0] https://www.youtube.com/watch?v=c3ar3lHClqA
> The irony is also that it would be way cheaper for people to develop websites as basic, old-school, reliable HTML pages with forms. Literal children were learning the "frontend" skills necessary to do that in the late 90s. HTML is designed to be easy to learn in a few minutes.
Cheaper to develop but who are you developing for? You won't have any customers. Customers demand JS-heavy sites by virtue of the features/interactions they ask for.
Devs don't care? No, users don't care and they will not reward you for making a HTML-only form website, no matter how they have complained about sluggish/bloated websites, they will continue to use them, even with alternatives available.
As an example, I recently had to pay for parking with a website because the card reader on the machine was busted. So I scanned the QR code and loaded up the site, had to fiddle to enable some of the scripts, and make my payment. After I was done, I saw it had used over 25 MB--4% of my data for the month--to collect roughly 30 bytes of information from me, assuming a naive encoding (16 digit CC, 3 digit CV2, 8 digit license plate #, 2 digit state). Maybe it also needed the billing address, so another 30 bytes or whatever. Point is the TLS handshake should've been 95% of the traffic.
If anything, I almost left to go look elsewhere because it was too much of a pain to get it to work on my phone and I didn't want to use up all of my data fiddling with it. No one is demanding a JS heavy site here. Customers are not demanding anything. It's a near certainty that no one has ever provided feedback to the parking lot owner about their payment form. I did actually leave digikey's store because I literally could not figure out how to get their payment form to work without blanket enabling all scripts (and they have a ton of third-party tracking scripts).
Sites that are for services that actually matter (e.g. banks, governments, utilities) also don't need to be flashy. You don't need to sell me on filing for my paternity leave or filing taxes or making a bank transfer or paying a bill. Just present the form. The absolute ideal website in such cases is a transcription of the paper form it replaces with a tiny bit of javascript to check constraints/field validation. The free tax filing website for the US is a decent inspiration for this: from a UX perspective it's just electronic versions of the paper forms with some ability to auto-calculate some fields.
> Customers demand JS-heavy sites by virtue of the features/interactions they ask for.
You have examples of these requests, no doubt.
> From what I can tell, Android can't even play two audio streams at once.
This is purely design-decision-based, it has nothing to do with the limitations of the hardware. A laptop with a weaker CPU than a flagship Android could probably stream and play hundreds of audio streams (no promise it'll sound coherent, though).
I'm 37, QBasic since 7, built my first Linux box at 12. (25 years ago. My god)
I have learned to appreciate, and let slide, a good hand-wavy "get off my lawn" formatted anecdote to relate history...if it owns it and isn't slippery in the process.
Here, we're sort of waving at "if websites weren't in JS, the imaginary phone would have loaded the imaginary page instead of saying "oh snap", which clearly indicated it was out of RAM"
Some errata:
Android can play more than 2 media streams at once.
A 2GB phone isn't a modern phone. I worked on Android and that was our Emerging Markets™ standard (read: dirt cheapest phone expected to work ok) in 2018, 7 years ago.
> Android can play more than 2 media streams at once.
From what I can glean that's only if the apps allow that, by not requesting the audio focus, and the documentation recommends to request it.
It's indeed very rare to find two (or more) apps that can play audio at the same time.
Not to mention that you can't set the volume of the individual apps (unless they have their own volume controls).
> A 2GB phone isn't a modern phone. I worked on Android and that was our Emerging Markets™ standard (read: dirt cheapest phone expected to work ok) in 2018, 7 years ago.
He might have meant 2GB of free ram, and so at least a 4GB phone.