Maybe people do care about performance and reliability
buttondown.email
buttondown.email
The licensing model of large, enterprise software does have ramifications for users on the floor. In this case it's because the software had a per-seat license and required expensive consultants to modify your forms and workflows. It cost millions of dollars and years to roll out SAP at a factory.
The software we were making was faster, could be rolled out in weeks, and was user-extensible.
The IT folks at said multinationals hated our software. It was the end-users that demanded it, and ultimately, won us our contracts again and again.
Performance and reliability matters! It let folks on site get more work done, faster, and with better reporting and insights than they had ever gotten with their bloated, slow, expensive, and difficult-to-use software from more "traditional" vendors.
It was a neat experience.
On the other hand, if everyone in your org outside of IT execs despise SAP -- and make no mistake, they do, every last one of them -- then maybe it would be productive to wonder why that is rather than blaming your idiot users.
why?
I got to ghost on a sales call once with one of our customers (I was a lead developer at the time).
From what I could tell their IT people didn't like our software because:
- They were already in the middle of a multi-year roll-out of SAP, integrating our software was a wrinkle in a plan they'd been working on for a long time
- Nobody got fired for choosing SAP, some saw choosing software from a small shop they'd never heard of was risky
- Annoyance: they were in charge of acquiring and rolling out the software the factories used! Why were the floor managers demanding that they integrate our software? What do they know about software, enterprise contract negotiation, etc!? How dare they!
- Support: they knew how to handle issues with SAP, user accounts, authentication, authorization, etc; integrating another piece in the mix across the entire company would be a whole project
It was a fun call to sit in on.
Ok, so this one I actually kind of agree with. Too many times I was in a position where a bunch of decisions were made about software or hardware, and then IT was brought in at the last minute to try and get it all to work in an unreasonable time frame. And then IT was asked it integrate it in impossible ways.
If another department brings IT in early, different story. I got in to IT to use technology to make people's lives easier, not to play with whatever the latest fad bullshit is or develop an inflated sense of self-worth. If some random nobody's software is going to do that at the cost of a minor annoyance to me, that's fine.
IT director: "Give me a budget to hire competent IT people"
Company: "On the other hand, we're ok with this IT incompetence"
I listen to several infosec podcasts, and one recurring theme in those podcasts is managing users who do "shadow IT", i.e. by buying and integrating new products or software that make their day-to-day jobs easier, but do so in a manner that opens up huge gaping security holes that IT doesn't even know about… until the breach happens and the company is all over the news for leaking customer data.
A good deal of “security,” even in the enterprise, is a lot of theatre and show boating. Write a formal specification and throw it at a model checker and you’ll probably start finding holes in most software stacks. But hardly any software developers do that let alone IT managers.
The later generation of the stuff I was working on at that company had to also be certified under certain important regulations. The system had to be able to be auditable in the sense that application logs couldn’t be repudiated in court and users couldn’t tamper with data. That was some pretty serious work.
But yeah.. there’s a lot of “lol security” out there and as an IT person trying to manage ISV solutions it can be a huge pain trying to sort the wheat from the chaff.
But just buying MS or SAP and thinking you’re done with security is also as bad. Don’t overlook security.
What makes SAP secure?
To re-emphasize my point from my original post: far more security problems result from the interaction of systems than result from systems themselves. SAP may be set up in a perfectly secure manner. The new product may be set up in a secure manner. However, their interaction may still result in data leakage or denial of service.
Even if your product is perfectly secure (which it isn't), the mere fact that it's one more component, interacting with all the other components of the company's IT infrastructure, is reason enough for broader corporate IT to be cautious.
Furthermore, it's often the case that when there is a problem, security or otherwise, it's not going to be your customer that's on the hook. It's going to be the company's IT department. Would you like to suddenly support a piece of software that, a week prior, you didn't even know existed, much less deployed at your company?
As a dev, I think about security in terms of exploits and making sure software doesn't have them (as well as having features required to implement user/data policies).
An IT person thinks about policies too but for them security is primarily about tools. If a piece of software will work behind their firewall and IDS, integrate with their monitoring software and Active Directory, export reports in the format this or that other tool needs, then it's secure from their perspective.
It makes sense when you think about it, and actually allows for a fair bit of freedom once you understand the boundaries. What is unfortunate is all the time I wasted gathering pen-test reports and all kinds of other junk when that wasn't the real problem at all.
"Travelers" are paper packets that move through a manufacturing process with whatever material is being improved. Lots of machine shops have these printed out packets of specs, communications and notes that accompany a given order as it makes it's way through the process.
I'm pretty sure the "daisies" comment was related to how many shops escalate a given order by adding bright stickers or other obvious, visual indicators to the traveler, and shops can sometime become so overwhelmed that everything is escalated and all the bright travelers start looking like a field of flowers.
How did the end-users even find your software especially when the IT folks hated it?
my boss said do it, because it was so much cheaper and no one could say when or if the SAP would be installed. They had to map the business to SAP, instead of having the software be flexible.
But it turns out when you build something that fulfills a business need and makes employees life’s easier they like it.. a lot. Even if it’s just a Lotus Notes database application. I even won a very minor award for that one.
this is both an advantage of SAP (and realistically, the ERP industry), and a curse.
As the end users got a taste for our UX, they began to threaten resignation if they had to go back to the old system.
Word of mouth and human competition are a hell of a thing. Once a branch manager sees how efficiently someone across the street is running their business (which is effectively identical due to mountainous regulations), they will start doing our marketing for us.
I feel like tuning software for the human factor is something that almost every MBA still misses to this day. Making "this software feels good to use" an explicit objective is clearly impossible. You have to want the experience to be good at a fundamental level. Its an ambient part of every item that merges. You have to care about the product and customer very deeply to achieve this.
So many miss this, and the big boys don't only miss the forest for the trees, they can't see the leaves either.
Total, narrow, limited scope.
Then big boys win by Hulk Smash. Startups win by leaves and forest.
And we cared deeply about the end users. One of the best things I did was get our development teams on-site with users. We had lunch with them, saw how they used our software, and took back tons of ideas for improvements and features that we released frequently and often. I got to know a number of our users on a first name basis and would use some of them to try out new features before we released them to the rest of our customers. It was awesome.
SAP is still the 800lb gorilla and probably always will be. It was neat to work in an environment where we cared this deeply about our users that they fought to be able to use our software.
Ease of use isn't something that can be measured though, and most people don't have the framework for arguing UX decisions so debates come down to "well I think this is easier to use than that". Maybe not SAP, but no matter how terrible a system is there's someone who's used to it and will argue that it's easier to use than the alternative, and that proponents of the alternative just need to get used to it.
I kind of feel like this is something a leader with a feel for it needs to dictate. Torvalds made a similar comment about good sense with Julian Hamano, which I don't feel effectively supports this, but I do agree with at some level.
If you have any influence though, can you ask for the dedicated & vps offerings to get more love. Hardware is terribly out of date now (lack of nvme & modern proc).
I realize DH needs to hit a price point & margin, so I’m not asking for latest gen hardware. Just hardware that isn’t a decade old :)
Back in the day at reddit, for example, we could see an uplift in usage when we made the pages faster, there was nearly a direct correlation.
At Netflix we spent a lot of effort on reliability because every time we had a major outage, there was a dropoff in subscriptions with the cohort that had been affected.
And I've heard similar from other people in the reliability space -- that there is no direct impact on retention from availability issues, but you can see an effect in the long term.
I know I care. If I pay for something and it sucks, I stop paying for it because it's not up to my expectations.
So they didn't cancel right after, but it does appear to affect their overall view of the service.
That’s what kills companies.
The resulting page loaded 10 times faster than what it replaced, which was a 'no code' option that the sales director set up. My solution was built with HTML/CSS/JS/PHP and contained authentication, accessibility, and a toolbox of modules for specific tasks that loaded only when needed (and still lightning fast). Scoring a perfect 100% in every test I threw at it.
The positive result of this change was immediately apparent. Not only to the agents and managers, but to the data team. The speed resulted in a full 130% increase in sales, across all agents.
Why? Well, the old script took time to download Google Fonts and a boatload of other garbage which put the page load at 2+seconds. This was dead air piled on-top of the delay caused by the auto-dialer. Meaning everyone we called had 3+ seconds of nobody saying anything. When this was cut to 1 second, there wasn't a telltale delay to work around in the sales process.
So at least in this case, it took the sales director to care enough, not the dev.
I built the entire thing in 3 days with zero assistance.
MS spent x months to build y, here it is in 3 days. etc. etc.
People do not realise how fast development and software can be if you design with those priorities. It's orders of magnitude.
The main question is "does it matter?" The answer depends case by case.
For example, if I am the PM for TurboTax Premier desktop software, I know that it's latent - but it probably doesn't matter in a way that deserves prioritization. Sure, my clients would like for the forms to load faster, but they care infinitely more about the scope of tax situations we cover, and the correctness of calculation. A person uses my product a few hours per year, so even if there's an accumulated minute of form refresh latency, it's just not that impactful. What that means is - if I have an "extra developer", I am going to direct them towards product scope and correctness, not latency.
On the other hand, something like VSCODE (an example the article mentions), speed is part of the value proposition. As a developer, I need to quickly change text, quickly look up a reference, quickly switch files, etc. If things are sluggish, it isn't just frustrating but limits my ability to do development work. So a user of a slow IDE would be very motivated to seek alternatives, since they basically live in the IDE. As a PM, I would absolutely invest in performance if it was making my product actually less useful.
It's like anything else, investment has a tradeoff. Chances are, whatever car you drive could have a faster 0-60 speed and in isolation, that would be great. But are you willing to pay 10x for the car? Are you willing to give up the seats and the trunk to make it happen? So your car may not have the best 0-60, but if it's an affordable family minivan that's probably the right call.
There's also situations in the real world too, coin counting machines apparently also delay showing the results because people won't believe that dumping a jar full of coins into a machine and having an instant answer can be accurate.
People also do it too, locksmiths may umm and ah when called out to pick a lock because if they do it too quickly customers can feel aggrieved at a large invoice or even feel less safe in their homes if they've seen their front door picked in 10 seconds.
1 - https://www.theatlantic.com/technology/archive/2017/02/why-s...
Normal people have no reference point to judge how fast or slow software and hardware should be, other than through direct experience. By adding fake delays to avoid being honest and perhaps reassuring occasional surprised users, vendors just screw with the mental frameworks people build, at scale. It's a wasted opportunity, too, because if you're brave enough to be honest about execution time and weather the initial wave of distrust, then you may become a new reference point for your users, who will now view your competitors' software as bloated.
--
[0] - Though recently I brought this story up with a locksmith, and he said he thinks it's just stupid and there are hardly any situations in which it would even make sense.
1. Some disreputable locksmiths (word gets around) - probably very few
2. A locksmith will try the fast methods first, if they work he wins, if they don’t he didn’t waste too much time.
3. After doing a lock once he could immediately redo the same lock much faster and this may make it look like he could have done it very fast to begin
In some cases I could see that being the case: if the core task fundamentally requires significant computing resources and margins are too thin to through more resources at it while remaining competitive. That's the "every grocery store has one cashier with a long line" story (except for stores that change the story, e.g. with self checkout or a pricing strategy that frees up some margin to spend on more staff). I wonder how much of the slow performance of tax software is attributable to this, and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt."
But it's also clear that there are technical decisions that can make the software slower for customers without making feature development easier or cheaper or faster.
(I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid.
For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "slow" because each API does its own complex IO operations, many of which are redundant across the 4 calls.
Is that technical debt? I have the opportunity to create a new API that optimizes the IO for my use case, and it would be 4x faster. But, it may never be "worth it" to do that because my feature is seldomly used and is still fast enough for the user to not lose productivity. So I would say that's not really a tech debt, just a technical tradeoff that was made.
In general, I find that a lot of latency comes from (a) reuse of suboptimal pieces/frameworks that accelerate development and (b) not taking the time to optimize. There are times when these are tech debt, and there are times when these are fine.
Well, I'd still call that technical debt. All debt is a tradeoff, and sometimes debt is worth it (or, at least, is judged to be worth it at the time the debt is taken on). In this case, it might be deemed worth it, and reasonably so, especially if there simply aren't enough competitors that this would make a difference at the margin, or if it's simply not feasible for any competitor to implement that same feature in the same time frame with the same amount of developer resources and make it perform faster.
If you're FAANG there is some chance you're overpaying by not doing the RSU cost basis properly.
Now, you can definitely make the case that this is mostly Coinbase's fault for not sending over the actual purchase date, but TurboTax charged me a bunch of money to do that import, so I feel like they should have done some basic quality control.
I don't trust TurboTax to get my taxes right, because last year they got it very, very wrong.
I don't think it does wash sales across different brokers properly though, but neither does anyone else.
What I'm objecting to is the idea that I'm not going to get my taxes wrong using TurboTax. They fucked up badly.
I'm certainly not arguing that the solution is to buy audit insurance from the same company that told me to overpay by several thousand dollars. Every penny I pay to Intuit is a moral failing on my part, and on the part of the legislature that succumbed to their lobbying.
What do you think the "real person" does? They put your data into TurboTax or equivalent.
A lot of people would live much easier lives if they believed this.
You can make a really half-assed filing and all they will ever do is send you an invoice for the difference.
In fact, you could simply not file your taxes ever and the IRS will eventually inform you of your actual tax burden, at which point you should probably pay accordingly. I've never gone beyond this point.
What you hear about and what they WILL get you for is deliberate fraud.
I gather from this comment that the software is only used by individuals filing their own returns, not by professional tax-preparers or accountants. The latter two certainly spend more than a "a few hours per year" in whatever product they use for preparation. When it's tax season and they have to get the work done by April 15, professional aren't going to tolerate a few more minutes per customer.
Usually, the truly bloated software (like a lot of edutech) is just because of regulatory capture. Most of edutech isn't judged by the market, but by committees of corrupt idiots, who always exist and for which the open market is the solution for.
It's an old joke at this point that you can tell when a person first became a serious computer user based on how frequently they save their work. My muscle memory for ctrl+s is so ingrained that I type it every minute or two in things like Google Docs that literally ignore it.
This gave me shutters. Maybe it is some sort of manual transmission-type feeling of control, but that is terrifying to me. Something about that feeling of owning when the source file is changed.
I guess more analogous to your "save" mechanism would be my git commit.
So my muscle memory is a lot of ctrl-a, c.
[1] A mistake that Chrome adopted afterward and didn't reverse until 2016: https://tech.slashdot.org/story/16/05/19/2041232/google-chro...
[2] Wasn't the only cause, of course. The request could fail as well.
How did I not know about this?? And it supports Firefox + (neo)vim!
It may also make sense to cache some search data and ping some network resources, because those dialog boxes don't just show directories nowadays.
Surely I would prefer them to do those asynchronously, but the UI designers seem to all disagree.
Yes, you're right, Ctrl-S is so deeply embedded in my subconsciousness that I will be probably pressing those keys on my deathbed.
There's still lean software. Mellel (for macOS, https://www.mellel.com) is a very responsive editor, with a style edit model that's a bit different from Word. But it takes a lot of work to make something increasingly capable and keep performance.
Earlier and later versions were worse, and Outlook was horrible if you were stuck on a domain.
Excel always had issues if you were doing something stupid like using it as a database and all of the apps had issues if you were being stupid with OLE via copy/paste or were using Internet Explorer.
Or tried to use Microsoft Equation more than a couple of times inside a single document. The thing was ridiculously prone to crashing on top of producing butt-ugly typesetting.
Of course, that falls under “using OLE”, but IIRC so does using WordArt, which was rock solid (albeit much simpler and in particular incapable of in-place editing).
I remember a long, long time ago firing up Access. I quickly closed it and continued to use Excel as a database. As it was only for personal use this wasn't an issue.
I hated Access and eventually abandoned it. Meanwhile, I pretty quickly decided that Excel is the fastest and overall best Microsoft product by a mile. I now just use Google Sheets, but if you have Windows and need to do lots of spreadsheeting, Excel is just by far the way to go. Far, far better than Libre Office, Numbers, or Google Sheets.
To be fair, I was rarely dealing with more than a couple thousand rows. If it were millions, and complicated joins, maybe Access (or probably SQLite) would be better, but oh my god, how is Excel so much faster and more polished than everything else? (Rhetorical question: Joel on Software has some stories that help answer.)
Pre-web I used it for internal process automation - it required less effort than anything else (including modern capable frameworks like Rails) to provide a lot of functionality to applications with a low number of concurrent users (1-20 users).
I do really miss that - this kind of app is now often implemented with a low-code platform (with expensive consultants) or a web framework (5-10x the effort required for the same results).
Word would start in less than a second (not sure which version it was), and most features we use today were available. Adobe Photoshop 3.0 would start in less than 3 seconds, and same with Premiere 1.0.
Of course you lacked some memory protection features which could make the whole computer crash because of a single program failure, but daily experience was much better on old systems. They felt way faster because they have less input lag and because UI was less bloated.
I'm not saying 1990s computer and software were better, but they were way faster than what we use today.
Anyone can watch this video [1] to see how long it actually took to boot up or launch Word. But bootup seems to take 20 seconds, and launching Word took 7 seconds. Which roughly matches my memory.
So about an order of magnitude slower than you're describing. (The SE/30 had a clock speed twice that of the SE, but launching things is mostly bound by the hard drive speed.)
Other things like saving a 3-line Word document took 6 seconds. Quitting Word took 6 seconds. Basically, everything was pretty slow back then.
In contrast, I just tried launching Word on my M1 MacBook, and it took about three quarters of a second. While saving a file is simply instantaneous, as is quitting. And launching Photoshop takes 7 seconds.
Edit: here's another video [2] opening Photoshop 2 which takes a full 28 seconds.
which got slower and slower taking swap speed with it, which slowed down everything you were actually using. You'd defrag the drive regularly and that wouldn't do it so you'd have to wipe and reinstall from scratch. And that was some hours of work but like having a brand new machine again when you were done. You couldn't believe how bad it had degraded to. The good old days or selective memories?
Defragging is one of those clear cases for time shifting things from your high value time to your low value time.
I'll try to make a video on real hardware once I have time to show that I'm not exaggerating. And remember that the SE/30 is a computer from 89, so not even early 90s.
But this matches my memory as well -- Photoshop was by far the slowest program I had at the time to start up. I remember being bored waiting because it just took forever to load. While applications like Word definitely took several seconds to load, but that wasn't such a big deal.
Of course, all of this was a vast improvement over the several minutes it would take loading programs on my Commodore 64 a few years prior... from cassette tape! ;)
I used an SE/30 well into the late 90s as a kind of boutique writing appliance. I never used Word, I used BBEdit, which opened rather quickly. I always felt getting the machine up and going was faster than a standard Windows desktop.
The SE/30 was a hell of a machine. I set up an SE for a friend in the mid-90s for her to write papers on, and she really liked using it and never complained about the speed (and she did use Word). Which is saying something, because the SE was kind of a dog.
A fresh System 7 install on an SE/30 would boot from a hard drive in ~20 seconds. Adding system extensions could double this pretty easily.
In fact, I'm going to directly relate this to Wirth's Law. I think there was a brief span of years where software didn't get slower as quickly as hardware got faster. My experience of the early 90s was that my computer was slow as hell, and those of my more well-heeled friends were incredibly fast.
I mean, we all know the answer was 0. Hell, the systems you're talking about were likely not networked at all. I have a feeling that if we took all the 'slow' software we're talking about and cut out all the pieces reaching for the network in one place or another that we'd gain about an order of magnitude of speed back. Of course we'd lose about that much in functionality.
Really succinct fast code probably takes more time than verbose, slow code.
It takes me a lot longer to write small code, than big code (CTRL-C -> CTRL-V).
A big part of my refactoring, is looking for copy/pasta, and trying to do things like refine base classes or protocols, and whatnot.
Is that really the case? Are 2010 skype and 2022 discord comparable in terms of functionality? Are 2000 winamp and 2022 spotify app comparable?
Todo app 15 years ago was a simple CRUD app. Today todo app has to do CRUD, sync, offline mode, public API, integrations with popular services, collaborative projects and support 6 platforms.
People whine about bloated web tech in app, and how good it was with native while forgetting that availability and feature parity on all platforms is a feature too.
I still remember how bad it was before electron as a windows user. Half the apps that seemed cool(omnifocus, bear notes) had mac only desktop version, other(1password, evernote) had a native windows version that felt ugly and unpolished.
The present day "apps" you describe are bloated because they bundle an entire web browser and more, maybe the equivalent of a container, to run the little sliver of JS/html that presents the UI to the user.
The reason they are bundled like this is to enable web developers to work on them.
Sync was done in many ways, thanks to the app using actual files to store information. It wasn't a concern of the app itself - nor it should be. Off-line mode was the default. Public API wasn't needed. Collaborative projects is something nobody asks for in a Todo app, and of course, portability gets much easier when you have much less code to port.
Still, I could imagine apps back then having all those online and multiplayer features[0]. But even then, this doesn't add up to modern bloat. APIs, collaborative editing, sync, integrations - these aren't compute-heavy or real-time features, they shouldn't cause a big performance impact. That is, unless you're doing something stupid, like blocking on network requests, keeping state on a server, or just constantly parsing and serializing JSON (or XML).
> Are 2000 winamp and 2022 spotify app comparable?
Yes. WinAMP reigns supreme. Spotify app is hot, bloated garbage and has only a small fraction of features WinAMP offered. The entire value of Spotify is in their service part - but music streaming existed in 2000. You probably could make WinAMP stream from Spotify if you tried hard enough. I hope someone does and uses this to demonstrate what should be obvious: there's no technial justification for Spotify being so heavy, so feature-less and so bad UI/UX-wise.
--
[0] - They didn't have them, because most of those features only became useful once smartphones and mobile connectivity took off in the earnest.
The UX of those phones was pretty poor though.
[0] - SyncML.
> The UX of those phones was pretty poor though.
That... really depends. Having physical buttons was nice. I could write on those numeric keypads about as fast as I do on full touchscreen keyboard today, except I'd make less errors and could do it without looking at my fingers.
Which brings me to one piece of feature phone UX I strongly miss to this day: fixed latency. The firmware/OS was pretty much (or maybe even de facto) a real-time OS. With few rare exceptions, every interaction had consistent, fixed latency. Because of that (and physical buttons), I quickly learned to operate my phone without looking at it, or even pulling it out of my pocket. Unlock, menu, down, down, OK, [wait 1 second], down, OK, start typing... - these kind of sequences quickly became muscle memory.
All that was lost with switch to smartphones, as both Android and iOS have randomly changing and unpredictable UI latency, and the UI itself isn't fixed in space either.
I mean, kinda but not really.
Back in the day a large number of us likely had huge (exceptionally legally questionable) MP3 libraries that we managed. And while, yea having 100GB of music with just about everything was nice, it is also a major pain in the ass. So much so that Winamp pretty much died after streaming (long with legal issues in MP3s) took over the market.
Now, if the music market wasn't legally locked down, would there be better streaming apps? I believe so. So it appears we may be asking the wrong questions. Not why apps are getting slower, but why it seems the market has fewer competing apps at all levels.
This is exactly the phenomenon I recently started describing on HN with the phrase "software is resisting commoditization". It's rare these days to see an app you could use for a while and then replace with an equivalent alternative.
I think SaaS is a big driver of this - by keeping important functionality (and user data) server-side, the user ends up being locked into your software. No need to rely on IP protections - there's just no way for them to pirate the bits running on your infrastructure. And even if someone reverse-engineered your APIs and built a better frontend, the users of that alternative would still be tied to your backend, and thus your service.
This means there's no business in making alternative frontends. Instead, it's better to start your own SaaS and go after a different market slice. Even seemingly equivalent products quickly drift apart, each optimizing strongly for slightly different audience. It's easier than to fight another company over their users directly.
A tailored set of features is a good "unique value proposition" for a while, but it may be too easy for someone to eventually replicate. Taking user data hostage is better, but users don't like it very much. The best UVPs seem to have nothing to do with software.
Spotify is a stellar example here: the real value they own isn't software or infrastructure, it's all the relationships and contracts they've established in the music industry. This moat is impervious to nearly all competition - unless you're insider on the music label side, or plugged into Softbank's infinite money hose, you're not going to replicate it. Spotify, in turn, doesn't have to give a shit about its music player anymore.
How to fix this? I'm not sure if it can be. We'd need to destroy the ability for businesses to prop their software with some unique propositions that can't be easily copied by competitors. I can't see it happening without a total overhaul of intellectual property and computer crime laws. Things like Data Portability section of GDPR help a little, but ultimately there's just too many ways to create those tiny moats that make applications non-substitutable.
Why else do I have to upload my fitness/health data to see it on my smartphone in addition to Garmin watch?
The increase in resources available since 200s is measured in orders of magnitude. Are there similar increases in software features that warrant the increased bloat?
> I still remember how bad it was before electron as a windows user. Half the apps that seemed cool(omnifocus, bear notes) had mac only desktop version, other(1password, evernote) had a native windows version that felt ugly and unpolished.
Now all apps are ugly and unpolished
In my opinion - yes. Most of what Spotify provides implemented in the cloud (on server side). Client is a UI to select and stream music. Winamp supported music streaming to but didn't have an advanced UI to select what to stream. I see no fundamental reasons why a desktop app for Spotify should use much more resources. Given open API it should be possible to make a Spotify plugin for Winamp.
I haven't used Spotify desktop app but can guess it is written using electron or something like that and this is the main reason it uses much more RAM/CPU than Winamp, not because it does more work.
My experience was very different, may be because I don't care much about how an app looks but care is it allows me to do what I need to do fast. Before electron most apps followed Microsoft UI guidelines, had consistent look and feel, hot keys for most functions with basic hot keys (like save/open/help e. t. c.) consistent in different apps, low UI latency (unless the system is swapping but electron made this problem worse by using more RAM).
It's true lots of software were unreliable back in the day. But: - Crashes sometimes != Slow, bloated, and unreliable. I'd rather have something simple and responsive that crashes every now and then, than something that is aggravating to use all the time. - With the massive increase in hardware performance, there's just no excuse at all for slow unresponsive software now, especially from the big vendors. The reasons are not even usually technical; the bloat is from ads and tracking and more
> I'd rather have a search take a second or two longer if it is able to handle synonyms and different word forms.
I'm not sure people are complaining abut search being slow. Most complaints about search is that is lower quality than it used to be.
> VS Code is so much better than Visual Studio from around 2000.
VSCode and Visual Studio are two completely different products, one is a code editor, and the other is a full blown IDE. There were very good editors back in the day. And VSCode has started showing signs of a decrease in quality.
What does Visual Studio from around 2000 have that VSCode doesn't? I get that VSCode offloads a lot of work to the language server and extensions, but it offers IDE-like features including auto-completion, code navigation, and the UI is more than just code editing - it integrates version control, a test runner, debugging, etc. What is it missing that makes it not a full blown IDE?
A visual GUI designer, for example. Also a visual database model designer. Code generation too, and more
These are resource demanding features
An example that stands out in my mind is Photoshop 7, CS1, and maybe (memory is a little blurry) CS2. It felt considerably more responsive running on a thermally-non-ideal iMac with a single core PowerPC G5 and spinning rust hard disk than PS CC does today on a well cooled M-series MBP or custom built Ryzen 5950X tower with a 7000MB/s PCI-E 4.0 SSD.
That's just ridiculous. Yes, Photoshop has taken on some functionality since then but there is no excuse for anything to feel laggardly on such powerful hardware when it ran great on comparatively pedestrian machines 15 years ago.
All you need to do to prove to yourself how bad things have gotten is to find an old PC (or VM) and load up a copy of Windows XP.
The amount of bullshit between mouse click & updated photons arriving back at your eyeballs is insane in 2023. Software used to be much faster than me. Now, it is significantly slower. The only things that are reliably better are our networks and hardware.
I saw a recent talk on Blazor wherein Steve Sanderson ran through an example in an old version of visual studio. Watching how fast the project loaded actually made me depressed in a real and deep way: https://www.youtube.com/watch?v=2nRDdeIMGVo (@ 45:15)
The idea that software is slower now is nonsense, if anything it's faster in general. It's using orders of magnitude more hardware, of course, but how is that a problem?
Compare what the latest greatest word processor does vs the equivalent from the 90s to what a computer game today does vs the equivelent from the 90s. The latter is what orders of magnitude of improvement looks like.
Now, in an ideal world you could get an 'idiot' version that would meet all your needs and run nothing extra and be nice and fast. Of course now you have countless different versions of software to release and test and hope nothing fun happens. Or, you do like everyone does and releases a big old binary of fun that does everything and give QA a few less things to do.
I won't say about word process, but spreadsheets?, well not many years ago many of them would stop working at 65k rows and say tough luck, and these days we have absolutely huge datasets running in them.
If I'm not using it, why is it slowing the application down? I don't buy this reasoning. Binaries are not big in modern terms and they don't go slower for including code that never runs.
This is ignoring the plethora of bad decisions in the past we're paying for now. Your word processor is likely running in a virtualized environment in your operating system because 30 years ago running full blowin programming applications with no security in your document was a good idea. Then you'll have another layer or two of anti-virus on top of it.
> Your word processor is likely running in a virtualized environment in your operating system
Is also not a good reason.
This is what we're saying! None of the "good" reasons given for why software is slow today stand up under scrutiny!
Spending hours upon hours every day getting an app snappier and snappier and watching the VS hog making everything so slow and sad.
I don't know how much the market really has a say in this. I don't use Slack because I want to. I use it because I must. When we had open protocols, you really could choose the best client. Nowadays everything is a walled garden.
It's amazing just how poorly we've managed to make a chat application run. Across the board companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs. Running a couple might be fine. Running more than that really slows things down. And developers tend to forget that most of the world isn't running a machine with the specs that they run with and many don't bother testing their stuff on machines with more limited resources.
I routinely have to kill applications when trying to build software or pair program because our video conferencing tools aren't light on resources either. I can't just add more RAM to my laptop because everything is soldered on now. That's another big difference from the past couple of decades. People could cheaply upgrade their hardware every couple of years. Now, you have to buy a brand new device, so people naturally hold on to their hardware longer. Mobile phone users are hanging on to their devices longer. Just yesterday we saw news that GitHub employees can only refresh laptops every four years. We should be working to make more efficient use of resources instead of targeting everything at the latest hardware specs.
Obviously there was old, bloated software. I think most of what people remember as being slow had a lot to do with spinning disks. I upgraded a family member's computer to something more modern not too long ago. He's pretty set in his ways and still uses old versions of MS Money and the like. It was amazing how much faster they ran. I can't know for certain, but I don't see that sort of future for JS apps. They're slow on considerably more advanced hardware. While more memory would help, more CPU cores likely won't.
I wish performance would be taken more seriously in the UX world. But, it costs less to cut corners and when you have a captive market, who cares? Once one company starts doing it, others do too, making it a race to the bottom. I'm thankful there are still indie developers building high quality, platform-native applications.
That's quite literally the market having a say.
The explosion of JS apps is a cost saving measure for vendors that given real choice, I don't think many consumers would opt for. The point is once you have lock-in and network effects, your customers don't really have much of a choice in the matter. At the very least, you can't say that's the market speaking in favor of the substandard apps any more than you can say it's the market speaking for any other choice the vendor makes.
As a related example, I'm sure people that were using 3rd party Twitter clients aren't feeling like the market has spoken and the best app has won just because Twitter killed off their API access. Their choice to stay on the platform has nothing to do with the their new-found love of the official apps.
The Linux point is interesting. I have a Linux workstation I use regularly (in addition to a macOS laptop) and sometimes the desktop integration is nice to have. I just also struggle to believe a company worth 10s of billions building tools for software developers couldn't solve the problem in any other way. It feels a bit like we let companies off the hook. Whatever misgivings people have about the UI consistency, we have plenty of Linux desktop software that runs well and developed on far smaller budgets. I could live with resource-hogging vendor software if there were open protocols or APIs in place to supplant with something of my own.
I still find it amaizing that it worked. A 486 is something like half the speed of a single core ESP32 today...
If it had 16MB of RAM, or 32, it could run better. A 486DX133 would be fine.
It's not entirely a myth. MS Word is not a representative example, though. It's been pretty awful from the start.
Today's software, on average, is very much larger and less performant than software from the olden days, and generally is not more featureful.
What is is, is cheaper to produce and modern software tends to have a much prettier (and graphical!) user interface.
With at least 20x processor speed, double the bits, and 1000x memory (let alone SSD's) I would have expected something better than what we have.
We also have better UX, more functionality, and better quality.
If people want to run the software of the mid-90s on modern hardware, I'm sure they can figure out a way. The upside is that when it crashes or you have to switch back and forth with modern software with greater functionality, the underlying system will let you do that very quickly.
Really? Do you think modern user interfaces are great? Everybody implements their widgets from scratch using html, css and Javascript. The boring old ui toolkits standardized a lot of features that are today non existent or different everywhere. For example a plain old list widget where you could select multiple items had standard ways to select ranges, to add ranges to a selection, to toggle the selection of single items, to select all of them. Most modern software doesn't have those actions. And even if it has some of them you have to find out how. Whereas such things used to be commonplace. Regularity of boring features is actually intuitive. Nice looking is not intuitive.
Install Windows 2000 and Office 97 in a VM. Word will be blazingly fast compared to the latest version. What features do you ever use in the latest version of Word that weren't present back then?
Things like word used to be much better in speed of the interface - it used to take fewer clicks to do stuff
Go open that Excel 97 with a spreadsheet containing 65,537 rows.... Oh, you can't.
People aren't building modern software that does the same set of things so attempting to measure it is much more difficult than opening up a zillon year old VM.
Most people don't care if their spreadsheet takes 1 second or 10 seconds to open. What they do care about is "Bob sent me a spreadsheet and I can't open it" or "The app crashed and lost all my data" (and technically I've seen spreadsheets crash plenty, but they tend to have a recent copy of the data saved which is eating up resources to monitor and do this). And things like "I want to hit undo 50 bajillion times".
And that is just feature bloat. There is a ton more 'just import a library' for that bloat because adding libraries is generally much easier when it comes to fixes then finding the place in your source code and fixing it.
And how quickly would the latest version of Microsoft Word start up on 90s-era PC?
Okay, so it wouldn't start up at all because the computer would not have enough memory, among other things. Let's say we built the absolute closest computer that could still technically run modern MS Office. We'd choose the absolute slowest CPU that can still boot Windows 10, the smallest amount of memory, and so on. It would still be many times faster than a 90s-era PC.
How quickly would modern Office open on that hardware? What about Office 95?
I was writing VB applications and could get the UI done in minutes, script it up and attach it to DCOM objects running on servers in hours. Whole applications done and dusted in a few days. It was easily the most productive environment I've ever worked in.
Now I'm writing Go in VSCode, and the language server + plugins + tools take forever (well, multiple tens of seconds). I have to run the UI in a browser, the server in a container, and the database in another container (with all the pain that entails). It's a mess and it's just not nearly as productive.
If someone invents a much better way (faster, easier, cheaper) to do some key part of a widely used product (operating system, database, file system, network protocol), they won't get any traction until they have built a competing product with all the bells and whistles around that technology.
That can be a formidable task to a startup founder with limited resources who has to try and compete with products that have huge budgets and decades of development behind them. Investors won't touch it until you have a completed and tested product with many customers already signed up. Customers won't touch it until it is a 'drop-in replacement' for their existing solution which requires resources to finish. Classic catch-22 or chicken-and-egg problem.
You can't just find a way to do something 10x faster and expect others to flock to it.
I have learned this the hard way. People are generally loss averse and resistant to change so making things better is often an uphill struggle.
As an example, I have worked on improving a build tool that is notoriously loathed in part for its poor performance. Part of the problem was that it was a jvm based tool and the jvm has terrible startup performance when loading lots of library code (the tool also made it easy to bring in dependencies so even small projects would often pull in massive amounts of vendor code). The only way to get a reasonably tight feedback loop under those constraints is to run tests in a persistent jvm process that can reuse the loaded classes from prior runs. The difference between using a cached jvm and a fresh jvm could easily be the difference between your tests running in tens of milliseconds or multiple seconds. I produced benchmarks that proved this.
But one problem is that any resource leaks in your code or the vendor code will eventually cause the jvm to run out of memory (which often would be a slow process of gradually degrading performance). For this and other reasons, people would often opt out of the in-process test running and fork a fresh jvm with each test run even though it could easily cost them hours of time over the course of a week. The problem was that using the in-process runner required stronger programming discipline. My claim was that code that could reliably run inside of the build tool without resource leaks is more desirable than code that cannot. It is also not particularly more difficult to write, but it does require skill and discipline. There was no tool to statically detect resource leaks so the burden does fall on the individual programmer. It was an exercise in frustration to try and explain the value proposition and argue with people with very different priorities from me so I walked away from the project but to this day it saddens me how much time is being sacrificed to the altar of poor programming discipline.
Often you want to position your product to augment their existing systems by addressing a clear gap and nothing more, solving a single serious pain point without actually replacing anything of note. This is simpler and meets less resistance in enterprises, and once inside it becomes much easier to attrit tasks handled by other systems. Land and expand.
The challenge for startup founders that want to avoid being a "drop-in replacement" is finding true gaps in the market that are also scalable. Obvious gaps almost always have a reason they are left unfilled.
Outside of pathological cases, even slow software usually is still lot better than no software and doing things manually, especially when the number of users is >1. I believe that is big reason why people do not avoid slow software.
Jira comes to mind as one example, where it seems almost universally hated by developers but loved by others, yet everyone (including others) complain it's slow, but damn if you cannot model near every single process in Jira if you'd like to.
Wordpress is another where performance is atrocious and security is usually lacking, but if you look for a plugin that does X, someone somewhere probably have already coded it for Wordpress.
Amazing solutions tend to have narrower focus. They tend to exclude complex workflows, forcing simplification. And there's an added bonus. The more admin tools you lack, the less likely management or other departments are to use your system. If they don't use it, they are less likely to be meddling with its configuration.
In short, Jira isn't a terrible product. It's a product that doesn't protect you from terrible people. ;)
It will let you do whatever you want.
I also work semi-offline a lot. My current internet connection is roughly 100 KBps. The connection in the underground isn't much better. I also work in airports and hotels. These pages that take 10+ seconds to load end up being abandoned.
Amazon famously measured how slow pages correlate with lost revenue.
You don't really notice this until you use something significantly faster, and you can stay focused on the task much longer. Things just work better. It's like using a sharp knife for the first time.
Still, it's an interesting question from the user's perspective. Reminds me of the downside of lazily-loaded images on the web. Whilst designed to help people with data constraints, it can have surprising side effects. The anecdote that comes to mind was a rural town in India where inhabitants would visit a particular place for internet access. They'd open a few URLs and just let it download, could take some 20 mins. Next, they'd return to their home to actually look at the pages they downloaded.
This usage pattern doesn't work with lazily loaded images, it forces them to scroll and wait beginning to end on every single URL.
My bookkeeping software has lots of 1 second delays and it's really annoying.
As a former Econ grad student, this is a case of what's called the principal-agent problem, which is a widely studied issue. From Google:
"The principal-agent problem is a conflict in priorities between the owner of an asset and the person to whom control of the asset has been delegated. The problem can occur in many situations, from the relationship between a client and a lawyer to the relationship between stockholders and a CEO."
complexity bad
say again:
complexity very bad
you say now:
complexity very, very bad"
No really -- I would bet that the single greatest contribution comes from the massive growth in complexity, in all relevant areas, over the last 20+ years.
Couple months back, I read an article that made a bold claim: that the old wisdom saying most software is IO-bound stopped being true some time ago; instead, most software nowadays is CPU-bound, typically on parsing JSON.
JSON is something that may seem simple to grug, particularly a webdev grug. So simple that they'll use it for structuring and exchanging data everywhere. But while on the API side it seems simple, actual JSON parsers and serializers are quite complex, and the format itself expensive to parse and wasteful[0]. All that complexity gets silently embedded into everything, and the overhead at runtime is paid at nearly every step and nearly every level of software stacks, even though most of it isn't even needed.
That's the failure mode of grug understanding of simplicity. Sometimes a little more effort up front yields much lower total complexity.
(Also, eliminating complexity is good. Shifting complexity from developers to users is criminal.)
--
[0] - It's better than XML in most scenarios, especially scenarios in which neither of them should be used in the first place.
Just wondering what a more complex but better solution would look like in this example.
Switch to protobuf. Or switch to CSV. Or switch to SQLite database files. Or stay with JSON, but reduce the complexity of the format, even if it means you need a post-processing step on your side[0]. Change overall design to do less back-and-forth. Batch requests and replies. Send just the required amount of information, instead of having the receiver discard 95% of the reply every time. Don't convert to JSON (or other ad-hoc stringly-typed serialization format) and back from it inside your own application process, just because it feels "simpler" than using a data structure[1]. Etc.
I get why people like using JSON protocols, even defaulting to it for ad-hoc ones. I do that too! It's the local optimum for protocol development[2]. JSON protocols are easy to extend and easy to debug. It's a good starting point when your protocol is in total flux. At some point, however, the protocol mostly solidifies. It should then be revisited and tightened up a bit.
The main benefit is of course performance. Even if the refactor can't simplify the architecture of your project (e.g. no possibility to batch things or reduce amount of places that do communication), what grugs often miss is that performance improvements alone can reduce complexity.
The canonical case here is scaling: switching from single-process to a scalable distributed solution is a massive jump in complexity. Keeping an eye on performance and removing (or avoiding) waste introduced for the sake of "simplicity" or development velocity will delay the point at which you need to switch to distributed solution. A little up-front cleverness and complexity now, plus a little spend to beef up your servers, may delay the switch forever. Computers are fast, we're just not using it, and grugs seeking simplicity by gradient descent and sleep-walking into high-complexity regions of solution space are partly to blame here.
--
[0] - I still shudder when I think back to a certain charting tool in the browser, that required on the text input side to be supplied with datapoints in the format:
[{x: 42, y: 100}, {x: 43, y: 64}, ...]
{x: [42, 43, ...], y: [100, 64, ...]}
[[42, 100], [43, 64], ...]
[1] - Sounds stupid, but I've seen this happen in otherwise sophisticated and somewhat performance-sensitive codebases. Beyond the waste coming from most of your data being passed around in pseudo-JSON strings, converted to various scalar and array types at the point of use and then serialized back, it leads to surprising amount of subtle bugs - especially when people manipulate the serialized format manually, because it's again "simpler" this way.
[2] - Every programming language these days has good JSON support built-in or easily available, it's hierarchical without footguns (c.f. YAML), it's plaintext and has good editor support, but still relatively compact (c.f. XML), it's malleable, it's browser-native, etc.
the mainframes are back with a vengeance, as basically everything nowadys is waiting for the network.
or! populating caches (phone book that has a few hundred names in it takes ages to load initially, start menu also, etc.) to avoid said waiting.
Computers are so ludicrously fast these days that in the majority of cases you do not need optimization at all. You do need de-pessimization though.
The pitch is that it should be useful even for people not using "down to the metal" languages - although at this point in the series they have been essentially:
* yelling at the sky that software is slow (amen to that)
* making fun at python for not being C (which is, I mean, true)
* explaining why memory caching is important (which is both true and not obvious to most people)
* diving into the details of SIMD intrisincs of x86 using some form of vectorized quantum hardware-specific instructions, which I'm sure is going to help me avoid a few calls to render in my React app _any time now_.
(Just kidding, I'm pretty sure I'm going to learn stuff from the series, which is the point.)
[1] https://www.computerenhance.com/p/welcome-to-the-performance...
Before I saw that video, if you had asked me to write a terminal I would have made one with essentially the same design as Casey. I didn’t even think that there is another way! Like… just draw the grid of chars. What else is there to do?! Why add extra steps?
Microsoft added extra steps.
To everyone that argues that premature optimisation is bad, that’s like saying we should go to the Moon by building a bus and then fixing any performance issues that prevent orbital insertion after it is moving down the highway successfully.
The wrong part is that you don't measure performance. Which was OP's point. Just measuring the performance is very hard, labor-intensive, resource-intensive task. "One of these day devs" mostly don't even know how to approach this task, but even if they knew, the mountain of infrastructure they sit upon, which is in many cases completely opaque to them will make it impossible for them to be productive (or do anything at all) when it comes to estimating performance of their programs.
Add to this also the fact that most things when it comes to performance are, basically, out of your control. If the problem is in the framework -- maaaaybe you can replace / patch the framework. If the problem is in the browser -- with a 0.1% probability you might convince users use another browser. If that's to do with OS in which the browser is running -- well, you, yourself, probably won't install a different OS only to make your own program happier...
But, the complaint isn't about the "one of these day devs", it's about the infrastructure in which they live that made it, basically, impossible to care about performance.
I've seen a couple out-of-memory deaths (mostly non-paginated db queries, but compounded with the inefficiency of py2), and occasionally an accidentally quadratic loop (which would be faster in C, but usually can just be made fast in Python with more thoughtful code), but it's almost always the DB—oops, I need to add an index, oops I did a cross join, oops, I'm spawning additional 10 queries for each row returned. The time spent in Python on a slow endpoint is usually negligible.
Dev: I get paid for writing features. I can write new features faster in {insert slow interpreted language here}.
Also if the company is of any size, whatever they write has to fit in the rest of their CI/CD stack and pass whatever kind of code review the company does or doesn't implement. So yea it's easy to say devs suck (and they do), but without looking at the entire process they are involved in it can be very hard to qualify why they suck and where the suckage comes from.
React has dominated the front end for years now & brought some great innovations, but it's dominance is waning.
> performance simply just isn't on the radar of a big chunk of devs these days
Many devs seek to optimize for career prospects. Since the majority of FE jobs center around React, these devs focus on React. As companies prioritize FE performance, the jobs related to performance follow & the mass of FE developers follow after that.
My experience is the opposite of this. It's usually the self-taught devs that care a lot about performance, and the formally educated ones who are willing to trade it away.
People that are formally educated tend to end up in large organizations based because HR like the idea of college degrees. Large organizations are process oriented. Somewhere above the dev the specification of the application is created. The dev typically does not get to choose their tools, instead particular versions of the tools are provided, the versions of the libraries they need to target and so forth. Also after the code is written it needs to pass any number of tools and gates and QA systems and UAT systems before it's ever used in production. In general the last thing the dev is thinking of is 'is this fast' and instead they are thinking "I have 400 things on my to do and I hope this doesn't get bounced back to me"
I know something we could do, at least for websites. Google could finally make good on their announcement and make CWV actually have a measurable impact on rankings. I work for affiliates/SEO people. When CWV was announced, suddenly they cared about performance. Then the deadline came and went and Google decided not to make it really count after all, and they stopped caring. You don't have to be better than your competition if you're not extremely slow, because either you're on 1 and you get the user, or you're not, and the user never sees your site (traffic on rank 2 and 3 drops dramatically, and beyond that it's barely noticeable).
If Google decided to punish slow load times, large layout shifts, huge payloads, and tons of JS by downranking the sites, you'd quickly have very fast websites all around.
If Google only relied on measuring itself, it would just be a cat and mouse game to identify Google's testers and serve them a stripped down version. But they already have the actual real user data.
We could start by stopping using these stupid pointless frameworks that provide little functionality but reams of overhead.
2) is a bit due to tracking, but usually mostly a consequence of the API-first design. Despite using a large and powerful framework, the app itself does very little locally, as anything non-trivial ends up being a blocking network request, or a burst of several such requests (usually not blocking the app itself, but almost always blocking the user from continuing until the requests are done).
However, I disagree with the author on global changes. I think we can do them. In fact, I think local changes can grow to global ones, or close to it.
Here's my personal plan: like many of you, I want to make money off of my FOSS projects. However, instead of going the donation route, I'm taking an entirely different tack. I am setting myself up as a professional. This includes accepting some liability for my software.
You can bet that if I'm accepting liability, I will be testing my software until it screams.
But the flip side of being professional means crafting software that is fast, and I'm going to do that too. Yes, I'll be expensive, but that software should be a massive lever as a result.
The bigger the lever, the more likely that that software will help my clients out-compete their competitors. Helping them do so is my goal because if they do, their competitors will have to start caring about performance.
And once people care about performance in one thing, it starts to disgust them to have to use slow software in other things. So it may be slow (over decades), but I'm hoping that my work will help performance go viral.
or is this satire?
Notice that I said that I will be expensive, not the FOSS. I meant that my services will be expensive.
So yes, I will. Thank you.
FOSS means free, depending on what you want from the software - if you want more than the FOSS offering does, you may have to pay for improvements, or you may not.
I can't help you with your disbelief, but it is true that nothing in the FOSS philosophy prevents companies from charging for their work.
I work for a financial services firm. We are consistently highly rated for customer service. One of the reasons that is the case is that our website is fast.
It takes a lot of work by our devs for that to happen!
I've been working with software since 1999, I've never seen any developer or manager worry about performance. I've seen a religious battle over formatting or using a Java library, or "it's not the Ruby way".
I never participated in any performance or reliability meetings, or projects, or religious battles.
In general, performance is only fixed in very extreme cases. For example, I worked on fixing code that generated a few megabytes of SQL. Or code that uses all of the server's memory.
And it's hard to get permission to fix some extreme bugs. The code that generates a million stored procedures after a few months still exists at one of the places where I worked.
At another company, I fixed a problem (infinite printing) that had been around for 20 years (I even made a birthday cake for the bug), under pressure from the biggest customer who couldn't use a report and no workarounds worked anymore. 20 years of workarounds.
You are sometimes seen as a radical if you try to fix the most absurd bugs. Today I document the bug and wait for the prioritization. Sometimes you fix it after 20 years...
Of course this is also to a point. 1 second versus 10 seconds to do a major software operation isn't going to affect most users. Now stretch that out to 100 seconds and priorities start changing. You get in the 'really annoying to people' zone.
I think one of the differences when looking at performance is how many times it is executed. I might pull up some customer record/ticket in SAP 50 times a day. If its 1 second or 10 seconds doesn't matter that much because I can generally interweave it with other operations I'm performing. Now, if for some reason I was executing that a million time a day, like a single database query, suddenly we're talking about an issue that's worth fixing.
I'm sitting here trying to replicate a service across multiple zones this mornin— oh, it's not morning any more sigh — and, well,
Code: ReconcileVMSSAgentPoolFailed
Message: We are unable to serve this request due to an internal error
But absolutely there is incompetence. I fielded this, this week: "the tests broke", "oh, sorry about that. I've introduced a bug. a while later It's fixed now." "the test is still broke for me?" "… you need to pull the fix…?"
I've got another dev staunchly refusing to enable the logging necessary to print tracebacks, … while simultaneously being perplexed by a bug we're facing. IDK what's causing the bug either … but, IDK, let's get some logs in the meantime?
Higher ups wondering "why can't anyone answer technical questions? How are our devs so incompetent that they don't know the answers?" after the entire team that managed the component to which the question is directed at has been laid off.
I've answered questions in the form of,
A: We do X. Here's a screenshot. <screenshot>
Me: Where in your screenshot is X?
A: Oh, you're right.
And of course I've a TUI version of it as well, with all data local (and synced to the cloud).
I really hope that once I'm ready to put it out there, I will find the right audience.
Reliability and performance doesn't matter to people who are chasing sales (which is most of a company, not just the sales team, because that's how company success is measured). Retention is someone else's job, and so the focus will always be on churning out more and more feature that can boost sales.
As devs we need to take pride in our work, even when it feels like there's a lot of pressure to cut corners and ship trash. Take a few extra cycles to make your system just a little bit more resilient and give positive feedback to your peers who do the same.
These are not the people buying these systems. It's someone much further up the chain. They often don't care if the software is a dog to use. Unless that means they need to employ more people.
That's partly because Moore's Law, Dennard Scaling, ... meant that our apps were going to get faster next year regardless. Intel had better marketing than Joe Programmer. So Intel got paid.
The slowest, most inefficient solution is (depending on the value of solving the problem) better than no solution at all.
As is usually the case - software, particularly SaaS, resists commoditization. For almost any piece of software you may be using (and I am counting things like social media platforms or e-commerce sites in this), there is no equivalent substitute you could switch to on short notice. Often there's literally none at all. When there is, the effort to migrate your data tends to be prohibitive.
Also, in my phrasing, I wrote "need" instead of your "want". From my observations, almost all interactions regular people have with software are out of necessity, in the sense that they're forced to use it to get what they want, and they have no power to change it.
Examples:
- Software your employer tells you to use at work, which sometimes is quite horrible, thanks to magic of enterprise sales.
- Software your government tells you to use to submit various forms related to taxes, healthcare, childcare, business, social services, etc. This sometimes manages to not be all that bad.
- Software your daycare suddenly forces you to use to communicate with their staff and access CCTV feeds. Software you can't ignore because absence reporting and invoicing goes through it too. Software that's hot garbage, surveillance capitalism optimized mobile app with no web version, created by some bullshit startup with lots of VC funding, which explains why, out of a sudden, every single daycare started to switch to it, despite the app being extremely limited, having abysmal ergonomics, discriminating against people who aren't glued to their smartphones, and likely violating GDPR in more than one way.
I guess you can tell I'm a bit bitter about that last one.
The company was acquired a year ago by an international giant, but it didn't really change on the inside.
So, what's the secret sauce? -- Exclusivity. Competition died off 10-15 years ago. The company used to compete with some big names in the field, but all those withdrew long time ago. So, we won.
Unfortunately, this is also a "success story" of many other companies, some of them I even had a (dis-)pleasure to work for. This is also a solid market strategy: don't compete, find a market niche where you offer a unique service. Once you are there, do the absolute minimum to make users happy: over time you will have accumulated enough features and unique workflows that are virtually impossible for the competitors to replicate, at least not with the kind of funding a typical start-up may go into town. Also, new features are easier to add, and they bring about as much of customer satisfaction as improving the old and broken stuff. The novelty factor makes it look like customers are getting more treats, but the treats are really low-effort.
In the case of a monopoly like the one I'm in, users feel trapped, often they don't even know how much better their software could potentially work, they accept ridiculous gaps in quality because there is no alternative. The requirements to performance and reliability are thus at the absolute minimum, and often lower.
---
Just to give you a practical example of what I'm talking about: recently, I discovered that some genius from the department which is responsible for the core component, a service that, beside other things is responsible for processing and saving configuration submitted by users has implemented "buffering"... nevermind that it's working on Linux, with filesystem API which already does buffering and caching... But, unlike Linux filesytem API, this NIH caching will lose user's data if the service stopped after acknowledging the save to the user and actually writing data to persistent storage. Nevermind that amount of data it has to write is negligible (at most few Megabytes). Nevermind that it's typically an interactive operation where users are in no rush to write such data...
I couldn't even convince the team responsible for the component that there's a problem... let alone do anything about it.
And, yes, our product used by some of the largest / wealthiest companies in the world.
>It’s well-established consensus that software is slower and more bloated than it was 20, 40 years ago.
That's an absurdly ridiculous statement presented as fact with no citations
Firefox ate Netscape's (edit: Mozilla Suite's) lunch.
Oracle eventually had to buy MySQL to stop the bleeding (and try to upsell).
So no. While people do prefer a 100% solution over a 90% solution, they much more strongly prefer a 90% solution now over a 100% solution that keeps them at work an extra hour or two nearly every day.