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.
You would have very fast landing pages, which you still do today. But the issue is SaaS apps are soul crushingly slow, but google does not care about that because google cannot login.
But SAAS apps don't get their traffic via Google. Their sales site does, but not the app itself. To get SAAS apps faster, you need upper management to care about the performance of the app, which they also don't. They care about a convoluted web of short-term ladder-climbing moves dictated by multiple layers of the principal agent problem.
Google gets data from the Chrome UX Report (CrUX, everyone can access aggregated data on Big Query), so they'll even get information on performance from pages they themselves never see, and "the origin" (aka the domain) is the most relevant group for most websites, because they won't have enough traffic on each individual page.
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.
From my experience looking at sites for improvement opportunities, if the site is ad-monetized, it's the ads, otherwise the frameworks are multiple times the tracking stuff (analytics etc). Oh, and of course google tag manager is used to load analytics and nothing else, because you need those extra 240kb of JS to feel complete :(
In my experience? For SPAs, it's mostly 1) bad use of the framework, causing way too many pointless DOM updates, and 2) doing lots and lots of network requests, and particularly blocking requests.
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).
> The more interesting question is “why don’t people avoid slow software.”
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.
Yeah, sometimes there are literally no alternatives or no alternatives "that have it all".
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.
I guess I'm one of the few developers that like Jira. If you can keep management from going wild with permissions and workflows, it isn't unpleasant to use. Granted, since it needs to serve everyone, it's not going to be amazing for anybody.
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. ;)
I can't avoid slow software because older, less bloated versions of mandatory tools in my industry (translation) are sunset with no recourse, and incompatible file changes mean I have to upgrade.
I think performance simply just isn't on the radar of a big chunk of devs these days, especially self-taught ones. Front-end wise, what with the trend of using frameworks (react/vue/etc) & a billion lines of javascript downloaded from npm, it'd probably be too much of a task to even begin profiling.
As a "one of these day devs" I only care about performance when it starts becoming a problem and I see nothing wrong with the way I'm going about this.
The problem is that performance and reliability are issues that creep up and by the time they're a problem, they are much more expensive to fix than if they had been first class priorities from the outset. Everyone who didn't care before finds new reasons to put it off because now it's so expensive to address.
Performance issues are also often trivial to head off from the beginning but require a rewrite to remediate later.
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.
> I see nothing wrong with the way I'm going about this.
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.
IMO it's unfair to blame the developers. Almost every developer I know loves working on performance stories. It's one of the few times we get to use our deeper technical and algorithmic skills and get a clear metric to optimize for. However, businesses are reluctant to prioritize that work and get impatient when they don't see new "features". I worked on a project where PMs would constantly complain to me about a particular admin page being slow. I wrote a ticket for them that would implement some optimizations (simple pagination and SQL optimizations) and asked them to prioritize it. They had time to complain every chance they got, but the ticket never got prioritized. I eventually got so sick of the complaining that I just took a Saturday morning and did it.
I dunno, I run into a lot of devs on reddit/here/etc that argue "who cares about performance just spin up more containers! I just wanna write {insert slow interpreted language here}."
The slowness of interpreted languages is frequently not the main culprit for slow performance though. Most load times in web apps I've worked on usually were spent doing inefficient or unnecessary DB queries or API requests.
This is the claim but it isn't necessarily true as often as it is claimed. If it was how would Stack overflow back in the .NET framework days have managed on I think 2 web servers plus a failover on the massive amount of traffic they do while also being responsive. There's 0 chance a python/ruby/etc web app could have done the same thing. And to think they could theoretically use less CPU and RAM on the same workload now running in .NET 6 which is dramatically more efficient than 4.x Framework.
Almost every single time I've had to deal with something being slow in the Python web app I work on, it's been a bad query, or bad ORM usage spawning thousands of additional queries to pull in relations.
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.
I think you're reading that the incorrect way, though it's hard to say. This is my take on it
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.
Some projects have performance as it's core proposition. Notably Solidjs, Astrojs, Qwikjs, among many others.
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.
> I think performance simply just isn't on the radar of a big chunk of devs these days, especially self-taught ones
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.
I'd almost split it out slightly differently, but I work indirectly with a lot of peoples code problems and this is just my own observations.
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 worked at a hole-in-the-wall-you've-never-heard-of software company that landed big contracts with large multinationals consistently that, from the customers' perspective, came down to one reason: it wasn't SAP.
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.
Oh you just need to support this XYZ new database, our app doesn't have a way deploy with your deploy tools, doesn't have granular permissions levels (in a factory environment), etc. Why do you not want our tool? Also, we will silo away a bunch of data needed for an MRP/ERP system to be effective to our system outside the MRP/ERP system. Silly IT people, not understanding our work environment (even though you support every person on the factory floor and have to understand their job and workflow to do that, to the point your techs are better manufacturing engineers than our actual MEs).
You sound like you're exhausted from dealing with people who are constantly doing end runs around your software. I can understand that.
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.
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
> 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!
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.
I would guess that completely incompetent IT departments that only degrades everybody's work are very highly correlated to workplaces that use those huge, all in 1, hired consultants based software packages.
My experience is admittedly limited but every case I've seen of IT being called in late was that IT would have reasons for no. The VP didn't even learn their lesson when circumventing IT ended up with all corporate e-mail down for nearly a week. (As predicted, although it ended up taking longer to fix because I was on the other side of the world, internet access but unreachable by phone.)
Another reason that people often overlook is security. Even if each individual software product has a good security model, differences in the way they interact can lead to security vulnerabilities and opportunities for attackers to move laterally through a network. In the case above, it may be that IT knows how to integrate SAP with their Active Directory system in a manner that ensures that users have access to the data that they need, without giving everyone write access to everything. A brand new product from some small startup, even if it's competently engineered, won't have the same pre-set integration playbooks as SAP. The in-house IT will have to figure it out themselves, which adds time and overhead for every operation. New hire? Before, you'd give them a SAP account, and you'd have a playbook that would automatically or semi-automatically provision everything for them. Now, you have to provision accounts in two systems. Compliance? IT already knows how to validate an SAP install for compliance and generate a report for the appropriate regulators. Now they're going to have to learn to do that with your new system. And so on.
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.
Security is important. What makes SAP secure? I personally found errors in customer systems. And at the time even Microsoft couldn’t implement OAuth2 correctly with regards to the specifications… which is no surprise given how often it had to be amended.
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.
Nothing, inherently. What makes SAP secure is that a lot of IT organizations have experience with setting it up, and know enough about its pitfalls to avoid them. With a new product, IT is going to have figure out the security pitfalls (hopefully by reading documentation, but more likely through testing, hopefully not through breaches). If, as the grandparent post indicates, the product was set up by someone outside of IT, it's quite likely that that person doesn't actually know about security, and may well have inadvertently opened a security hole by, for example, creating an insecure proxy account.
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?
To your point: I remember going to our IT security people asking for them to allow us to add Python to our computers. We said, "there's nothing in Python that Excel can't do" (not 100% true). Their response was, "If we could prohibit everyone from using Excel, that would be our preference too."
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.
Exactly. A lot of developers focus on lack-of-vulnerabilities as the essential aspect of security, when, in reality, for corporate IT, the essential aspect is visibility. It doesn't matter how secure a black-box app purports to be, the mere fact that it's a black box that IT has no visibility into it will (justifiably, IMO) lead IT to treat it as insecure.
And that's all fine, but when the IT Department turns itself into a black box and doesn't tell anyone what bar software needs to clear to be used that's when shadow IT happens.
At one point I wore a hat in a IT leadership role for factories. We hated third party software because it created silo's where our data became un-usable. There is no point in an MRP/ERP factory system if all the bits aren't talking/working together. People fight and fight you as you try to get there, but once you get there and it all starts to work together and you no longer have jobs travelers looking like daisies with escalations all over they get it and their life gets significantly better.
"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.
Our sales people had connections in the industry that led us into various "approved vendor" lists. This eventually allowed us to worm our way into getting demos with floor managers who could use some of their budget to buy our software. Word of mouth spread from there and within a couple of years we were driving their IT department up the wall. It was grass-roots and the end-users, the people on the floor doing the work, loved it so much that it spread.
And probably broke their MRP/ERP systems. But the IT departments probably came up with workaround to get data out of the system and feed the ERP/MRP system just enough to keep things going but probably way less efficiently than they would have ultimately been if pain points would have been addressed in the existing system instead of the virus of your software injected inappropriately. And then you probably badmouthed the MRP/ERP system for it's failings (that were partly related to the damage done from using your system). Weak sauce man. In a different life I wrote best of breed department level software too but at least I very much understood why enterprise systems were preferred outside the department so that I COULD ADDRESS THAT CORE ISSUE THAT NEEDED TO BE ADDRESSED AS PART OF MY SOFTWARE. But yea, IT department bad, me good.
Haha, yeah I get that. That's why I sat in on calls with their IT folks. We made it as easy as we could to get data back out of our system. We exported in a bunch of different formats and could integrate with several ERP/MRP/BI systems directly.
My first software job was doing custom lotus notes database applications. One of the ones I was working on was going to be overlapped by future SAP implementation..
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.
I've had similar experience working on a B2B product that we sell to financial institutions.
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.
I think this is ultimately what won over our users and why they championed our product so hard. A manager at a factory would use their budget to buy our software off their approved vendors list, get it going in a couple of weeks, and within months they were among the top performing factories. As word spread and other sites adopted our product the same trend happened.
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.
Software developers miss it too. Most libraries are pushed for how efficient they are, how few allocations they have, which algorithms they use, etc. regardless of in what circumstances they're being used, and easy to use libraries are assumed to be making a significant tradeoff.
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.
Off topic: I’ve been a DH customer since 2004 and love it because to me it’s the perfect PaaS. DH is way under appreciated by HN crowd.
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 :)
This seems…tangent with…my experience at another small company doing integrations with enterprise software like Sage. The various enterprise systems of course had their own reporting solutions, but customers preferred how ours let them build their own or request designs that they could modify using skills they already had: Excel and Windows.
The idea that software wasn't bloated and slow 20,30+ years ago is just myth. Everything was bloated and slow. MS Word in the 90s and 00s would regularly crash and take your file with you, and it often took minutes to start up. Yes, there were some brilliant counterexamples, just as there are today. But most software today is far more enjoyable and rapid to use than that from previous eras. While the software isn't as snappy as it theoretically could be, that is mostly because the market finds the tradeoff between features and speed. I'd rather have a search take a second or two longer if it is able to handle synonyms and different word forms. VS Code is so much better than Visual Studio from around 2000.
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.
> MS Word in the 90s and 00s would regularly crash and take your file with you,
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.
I remember playing “Maniac Mansion” for 12h without saving. Right before the end my computer crashed. All was lost. But at least I did the second run in 8h.
My IDE auto-saves as you make changes, yet I still mash ctrl+s frequently. I think it's mostly games that gave me the habit though. PC gaming has always been a gauntlet.
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.
The most annoying thing for me is that the idea of take something similar, make my changes to it, and save it under a different name only mangles the original file in today's world.
It is, because arguably the more common case is wanting to save a snapshot under a different name and continue editing the original. "Save as", unfortunately, does the opposite.
I, personally, want save to act like committing a transaction. I don't like making changes to something and having every key typed or item clicked on be an immediate change to the file. The common case for me is to start making changes, then save them when I'm ready, sometimes as another file name. At least 30 years of this behavior has been ingrained into my workflows. We have undo, but I'd also like to have a revert changes option that acts like rolling back a transaction. The simple rollback is to just close the file without saving, but that doesn't work if every change big or small is a commit.
Felt the same way after first going from eclipse to intellij. This fear, this lack off. But after a while i didn't notice anymore and i have never run into a situation where something important was lost.
In the opposite. Saving and making copies and even duplicating code in a file like an older version of an sql statement is some kind of fear/hoarding impulse, that doesn't seem to pay off at all.
I felt the same way, but there are three layers of defense for me, in order: robust undo, git commits, and the IDE maintains a history of its own with a certain number of revisions back in time.
Pretty much every time I finish typing something I end with ctrl+S. Its muscle memory from the old days, but now it triggers vs code to format whatever I just wrote, which is a convenient side effect.
To this day I always copy comments to the clipboard before submitting them or after I feel like I've put a lot of work into them -- owing to dubious browser UI[2] c. 2000, where e.g. you might accidentally lose focus of the text field, and then the backspace button would navigate backwards[1] and lose everything you had typed up.
This is my Jira trauma resurfacing thanks. I'm quite heavy on technical explanations, like to put a lot of context, links, references, alternatives, notes in my tickets. Now I just write with outlook (less formatting options than word, actually saves my 35-pages-long shit while typing and people can read it without logging into some slow monster, and I can insert images really fast inline) and save to add an attachment to Jira.
Still possible to lose data in the modern dubious UI on the web, so you could an extension like GhostText and type comment in a regular text editor where you. get recovery for free even if both apps crash
I may have lost days on aggregate from just waiting many seconds for the browser to respond after an accidental Ctrl+s that triggers "Save Page" - why is that operation so slow anyway?
Open office had autosaving functionality about 15 years before MS Office managed to figure it out, despite loss of work due to unexpected power outages or Office freezing up was a regular occurrence for everyone I knew back then.
Well, MS Word 5.1a on a mac ran really fine, as did all the Apple/ClarisWorks software. Word Perfect on a PC ran fine, too. Then came the inevitable bloat. Later versions of MS Word didn't run that smooth anymore, ClarisWorks became unsufferable. WP killed itself.
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.
Interesting...I remember MS Word 5.1 on Mac being slow and crashing so often I was saving a new document every minute or so. Word Perfect (on the same mac) was stable and fast. But feature-wise both were complete for me - then and today I guess.
That is only partially true. Office 2000 and 2003 were great releases, the main applications (Word, Excel, Access, PowerPoint and Outlook) were fast and stable as long as you weren't running some weird corporate domain deployment.
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.
> Office 2000 and 2003 were great releases, the main applications (Word, Excel, Access, PowerPoint and Outlook) were fast and stable as long as you weren't running some weird corporate domain deployment.
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).
> Excel always had issues if you were doing something stupid like using it as a database
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.
When I first started using spreadsheets professionally (Excel 2009), I was confused—how do I name the columns? Surely you don't just enter the column names in the first row! I also tried putting my data into Access.
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.)
Shame as Access is really powerful and far easier to use than Excel if you're familiar with SQL.
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).
When people say 20-30 years ago they actually mean 40-50 years ago, because it's the same people that have been saying the same thing for 20 years, picturing in their head the handcrafted assembly QuickDraw routines.
I would tend to disagree. In the 1990s System 7 would start in a few seconds from hard disk on a Mac SE/30.
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.
>but launching things is mostly bound by the hard drive speed.
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?
As recently as 2015 I was advising people that if you finish your work too early to go home, you should spend your time on updating our docs, defragging your hard drive, and reading the docs for your tools (eg, learning keyboard shortcuts or optional flags).
Defragging is one of those clear cases for time shifting things from your high value time to your low value time.
Oh, when I was younger I was mesmerized by watching all of the little squares in the defrag tool change color and move around. It was like someone tidying your room for you!
Windows reinstall every few years still gives a performance bump IME, nvme SSD be damned. It’s hard to keep a windows installation clean with all the startup junk that worms its way in over time.
On the video you sent Photoshop takes 6 seconds to start and it seems like it is stored on an external disk which could explain why it's slower.
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.
I checked again. He double-clicks the icon at 16:28 and the watch cursor ends at 16:55. That's 27 seconds. I might be off by a second or two, it's hard to measure exactly.
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! ;)
Bootup taking 20 seconds is consistent with my memory as well. It's a bit of a stretch to say that's "a few seconds," but it's not wildly off. 20 seconds is pretty fast, especially considering the anemic HDD speeds of the time.
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.
I mean, it's also possible that that's because the SE/30 was running software designed to also support slower machines like the Mac Plus, Mac SE, or Mac II? The SE/30 was kind of a beast when it came out.
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.
How many wireless networks was System 7 trying to connect to?
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.
How bloated software can become is limited by available hardware resources. 20-30 years ago typical RAM size / CPU core count where much smaller than nowadays. If you run desktop software written 20 years ago on modern hardware it would work much faster than modern desktop software with comparable functions (not always, but quite often). But I'd agree that there was plenty bloated software which run slow on hardware most people afforded at that time. May be this happens because software is typically developed on top of the line hardware but users on average spend less on hardware then developers.
> with comparable functions (not always, but quite often).
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.
Yes, they are all equivalent. There are variations in specific features but it should be obvious how irrelevant that is.
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.
> 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.
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.
"Feature" phones from 20 years ago (most Nokia and Ericsson even into the android era) could sync personal data such as phone book and calendar over the internet [0]. The libraries doing this were originally written in C and their compiled versions took up maybe tens of kb running on constrained hardware. The functionality is not remarkable.
That's true. But I think the critical mass wasn't there yet, those features weren't used much outside of business circles.
> 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.
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.
> 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.
Newer software in most cases has more features but do we all really need all this features? All features I use in the newest MS Office where already present in Office 2000. Sure there are people who use features added recently, but if only a small fraction users uses a feature it can be implemented in a plugin (given an architecture which allows independent extensions). This way all these new feature would not increase startup time and would not send OS to swapping if you don't have enough RAM.
So now it is bad everywhere. Good user facing software integrates itself into the platform so that the user can combine multiple tools. That got completely lost through the "app"-ification of all desktop software. They only integration that is done nowadays is done through cloud APIs. Half of the time they are done to sell tje users data and not to fulfill the need of a user.
Why else do I have to upload my fitness/health data to see it on my smartphone in addition to Garmin watch?
> Are 2010 skype and 2022 discord comparable in terms of functionality? Are 2000 winamp and 2022 spotify app comparable?
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.
> Are 2000 winamp and 2022 spotify app comparable?
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.
> 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.
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.
> VSCode and Visual Studio are two completely different products, one is a code editor, and the other is a full blown IDE
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?
It depends on the software in question, but yeah, a lot of it actually was faster even on era-appropriate hardware.
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.
> The idea that software wasn't bloated and slow 20,30+ years ago is just myth
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)
Days ago I ran W2k, something I missed between Windows 98 and Windows XP, just for fun, under a VM, with no Direct3D hardware acceleration, just KVM accelerated virt-manager. The virtual machine ran faster than the GL accelerated Mate DE in the host.
He's running 20 year old software on today's hardware, of course it's going to be fast.
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?
Because it isn't providing orders of magnitude more utility in exchange.
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.
See this is a particular problem.... You don't use 100% of the features of your software, hell, you might not even use 50% of the features. The problem here is one of measuring YOUR net utility of the gross utility realized by all users.
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.
> 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
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.
If by never runs, you mean things like automatic grammar and spell checking, which way back when were things you'd click a menu to run, and now are constantly running reassessing your lifes worth every time you click a new key. There tend to be any number of 'small' things like this that add up over time and suddenly we're running slow. It also doesn't help many applications followed the Apple school of thought and remove any configuration options so you're unable to disable much of this.
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.
Dude, I can run the entirety of Windows 95 in a VM (itself running in a browser) and Word from that era on top of it and it is still orders of magnitude faster than Word today. So
> 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!
Having spent years and years with visual studio, I can guarantee it didn't function like that on the computers of the time with the typical software/driver load. He's running that on a VM that is vastly faster than what you could get at the time.
Running Visual C++ 6 long past its prime was qiote a nice experience, before I had to switch to VS2005. Sure was nice to be able to have for-loop variables not spill out the loop scope but it was depressing as hell to see a very nice and responsive machine keel over.
Spending hours upon hours every day getting an app snappier and snappier and watching the VS hog making everything so slow and sad.
> While the software isn't as snappy as it theoretically could be, that is mostly because the market finds the tradeoff between features and speed.
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.
Kopete did the same Slack does today (with inline Youtube videos and LaTeX equations) with KDE3 running in the background under a machine with 256MB of RAM.
> I don't know how much the market really has a say in this. (...) companies are using JS-based apps not because it necessarily leads to a better user experience but because it reduces their costs.
I'm sorry, I did phrase "companies are using JS-based apps" poorly. I meant it to mean that software vendors were delivering JS-based apps. That "(...)" you used is pulling a lot of weight. You deleted all the other context I had and stitched together two paragraphs.
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.
JS apps have bounded the crappiness at the bottom end of SW competence. For example MS Teams can now be run in a browser tab where the bad stuff it can do (on purpose or thru security holes) is bounded by the sandbox and it works on Linux, unlike predecessors.
The security sandbox is a fair point. Although, embedding a web browser brings in a whole lot of extra surface area so you need to update regularly to stay secure. Electron's defaults have historically favored developer-friendliness over security and require a level of diligence from the app developer, as well. It's gotten better, for sure.
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.
There's another difference which is a stretch of time in which personal computers got faster a lot faster - often faster than than bloat could catch up (for a bit). That produced periods in which some previously slow-seeming software got quite snappy. This naturally stopped happening with the same regularity but it still does, occasionally - e.g. the excitement over M-series Macs.
Microsoft Word 97 might have felt laggy when I ran it on a first-generation Pentium CPU, but the race to the GHz bailed it out. Now that Moore's Law is running out of room, what's going to bail out this generation of software bloat?
The widespread availability of high-bandwidth and low-latency Internet access is what's been bailing out the latest generation of software bloat, not individual CPU performance.
I remember using Corel 8 on a 486 with 8MB of memory. I would write the text in notepad and paste it into Corel, otherwise it would take 2s for each letter to appear.
I still find it amaizing that it worked. A 486 is something like half the speed of a single core ESP32 today...
Only as a corollary, to put things in perspective, in the early '90's that was Windows 3.x on a 33-66-100 Mhz CPU with 4, maybe 8 MB (yes megabytes) of RAM and programs had a splash screen to mask the fact that they were very slow loading.
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.
exactly correct. The question is not: "was software bloated in the 90s". It's: "given that hardware capability increased in by several orders of magnitude, did software quality/speed see a similar increase?" The answer is a resounding no. It would be like moving from a tricycle to a supersonic car and somehow taking longer to get from point a to point b.
I'll concede that we're not going supersonic, but our speed is maybe more at 100mph than slower. Computers (including phones, accomplishing the same tasks that desktops were) are absolutely faster than they were.
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.
I dunno, we have ridiculously amazing displays, live video, amazing audio, intuitive, reactive interfaces, and profound knowledge at our fingertips. Seems like we're doing pretty good!
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.
> The idea that software wasn't bloated and slow 20,30+ years ago is just myth. Everything was bloated and slow. MS Word in the 90s and 00s would regularly crash and take your file with you, and it often took minutes to start up. Yes, there were some brilliant counterexamples, just as there are today. But most software today is far more enjoyable and rapid to use than that from previous eras.
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?
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.
This is an irrelevant question if you're in the business of selling most software.
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.
> MS Word in the 90s and 00s [...] often took minutes to start up.
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 think part of the reason for this myth is that if you run old software on a modern computer, it's blazingly fast. That doesn't mean it was fast back in the day too.
Disagree. VS in 2000 was the most productive environment I've ever worked in.
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.
A big part of the problem in my opinion, is that people are generally not interested in investing (money, time, effort) in technology. They focus almost exclusively on products. The short term is always given a much higher priority than long term.
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.
> 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.
The positioning heuristic is to never sell a "drop-in replacement", there are myriad reasons that goes poorly. In addition to the problem of feature parity, you also have the extremely painful and expensive implied migration which companies are loathe to do if at all avoidable, you will show up as a threat to the companies you are replacing, possibly with much larger marketing budgets for pushing you out of their market, and you have people whose job is tied to the thing you are replacing quietly sabotaging the deal inside the customer. 10x performance usually won't cover the cost of these issues, in my experience it requires more like 100x performance before the customer calculus starts to swing in your favor.
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.
I think there's actually something in this. That's why I've created my own CRM/ERP system. All page loads that are slower than 100 ms is considered a bug and I'm usually on under 50 ms.
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.
Alternate (and I think more accurate) phrasing: people tolerate bad performance and low reliability when there is no viable alternative tool that does the things they need.
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.
I'm going to pre-emptively link Casey Muratori's Refterm Lecture Part 1[0], because invariably when this topic comes up people are all "but optimization takes time and we gotta push the new features right now or the market will eat us."
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.
Timing being nice, Casey just started a series on performance / optimization [1].
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.)
The hilarious thing about the whole RefTerm thing is the armies of people defending Microsoft by saying that Casey is some sort of Dark Wizard and that his skills are magic and unique, which is why nobody else can reproduce his approach.
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?
At my previous job I was given permission to fully rewrite the call centre script/tooling used by sales agents. I also came from that team, and took a quick detour to the data team before finally landing in a development role. Giving me a full understanding of not only the agents needs and wants, but the limits on data being fed into this system.
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.
Also, many companies and people seem to have forgotten (or never learned) that small teams outperform large ones. There is a point past which every additional person will make the project take longer, and result in lower quality.
Great story, but I think the last sentence can lead people to wrong conclusions. It sounds to me like you spent more than 3 days on it. A crucial part of what you did, IMO, was to figure out what's needed, how you could do it, and then convincing people it's worth doing.
because normal people r dumb and they will always think there poor hardware is not enough to run bloated software slows so buy more whole android phone market is like this.
I like how this article highlights the complexity of many competing factors. We like to understand things by boiling them down to simple rules and catch phrases that make us feel like we understand the world but that is almost never how things work.
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.
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.
Every time I see this posted somewhere it's been long enough for me to forget about it, so I go through and read it again and glean something new from it.
Some of the complexity is, unfortunately, introduced by grugs, because complexity smarter than grug and sometimes pretend is simple.
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.
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}, ...]
Maybe this is because it matched the internal representation (if so, I do have some thoughts about it too). But doing it like:
{x: [42, 43, ...], y: [100, 64, ...]}
or:
[[42, 100], [43, 64], ...]
would easily cut the input size by 50% or more, meaning that much less work for the parser in the library and the serializer generating the input text. This shorter format is arguably more human-readable too!
[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.
what? no. most software is 100% architecture bound, because with the available tools and time budget building a synchronous client-server system is the max-bang min-buck solution.
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.
People care about features. They don't care if a page takes 2 seconds to load or has a thousand npm packages holding it up. They care that they can click a button and it does the thing that they need to do to accomplish their task. This stuff is all magic and pixie dust to 99.9% of people. And if adding the new feature creates bloat and slowness, so be it. If this tiny little seemingly insignificant thing that user wants is not there, it doesn't matter to them if you have to completely break your "architectural purity" and hack something gross that messes with your Lighthouse score to put it there. It just needs to be there.
Microsoft had to force people off XP and then again off Windows 7.
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.
I've worked at a number of big companies that have run experiments on TTI & response times and they've all shown statistically significant results that responsiveness impacts revenue, engagement & retention.
People don't directly care about performance and reliability, but it does affect their behavior.
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.
What's the difference between caring and affecting behavior? If people cancel their subscriptions after a major outage, wouldn't it be reasonable to interpret that some of them cared about performance and reliability?
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.
I wrote it poorly and can't edit now, but what I meant was they cancelled 3-6 months down the line at a higher rate than those that didn't experience the outage.
So they didn't cancel right after, but it does appear to affect their overall view of the service.
I think people do care about these things, but they don't always know what it is, precisely, they're caring about. They just know that the thing they have is disappointing.
These features always matter, but they matter the most when you have competition. When the other guys’ retention problems become your selling point, you are making money off of them.
100% work at another big-ish tech company on the networking stack and every time we decrease latency, we usually see an increase in traffic as more page loads succeed. It's still quite hard to make the case to PMs and business leaders that there's more latent demand left for our product at lower latency levels, but it's also hard to quantify that extra traffic into revenue vs costs of latency decreasing.
Zoom (videoconferencing) was started by a former Cisco WebEx employee who was fed up with how sucky WebEx was, and decided to do something about it. So even in the enterprise space where the payer is not the user progress can happen.
"It’s well-established consensus that software is slower and more bloated than it was 20, 40 years ago." says it all. I see now why the suckless community makes the position they do.
> Programmers want to write fast apps. But the market doesn’t care.
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.
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
At some point/level, Azure can't¹, so I can't. There's GCP, but high switching costs. (¹this is a fractal error, too. Part incompetence, part societal and economic factors way out of certainly my control.)
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.
Often enough that sometimes I wonder if ChatGPT hasn't already replaced some of the people around me.
279 comments
[ 2.7 ms ] story [ 264 ms ] threadI 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).
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.
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"
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.
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 :)
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.
[1] https://www.youtube.com/watch?v=g0O7heFHA-k
[2] https://www.youtube.com/watch?v=LP_JNatS2Sg
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.
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.
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.
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.
https://www.youtube.com/watch?v=pgoetgxecw8
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.
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.
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.
>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
complexity bad
say again:
complexity very bad
you say now:
complexity very, very bad"
https://grugbrain.dev/
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:
Maybe this is because it matched the internal representation (if so, I do have some thoughts about it too). But doing it like: or: would easily cut the input size by 50% or more, meaning that much less work for the parser in the library and the serializer generating the input text. This shorter format is arguably more human-readable too![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.
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.
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.
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.
I'm sitting here trying to replicate a service across multiple zones this mornin— oh, it's not morning any more sigh — and, well,
At some point/level, Azure can't¹, so I can't. There's GCP, but high switching costs. (¹this is a fractal error, too. Part incompetence, part societal and economic factors way out of certainly my control.)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,
Often enough that sometimes I wonder if ChatGPT hasn't already replaced some of the people around me.