I can't pay rent because devs just don't care

> 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.

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.

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.

>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 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)

>> 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.

>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?"

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?

The same reason it takes longer to write a shorter letter. Nothing is free, removing things costs time.

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

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.

> "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.

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.

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.

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.

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

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.

How about if no technology is required at all to receive services related to the "critical path for life".