Live data from Hacker News

Maybe people do care about performance and reliability

buttondown.email

211–220 of 280 posts

Re: Maybe people do care about performance and reliability

#211
post #199

Earlier quoted context omitted.

> 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 i…

"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. The UX of those phones was pretty poor though. [0] - SyncML.

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.

Re: Maybe people do care about performance and reliability

#212

Earlier quoted context omitted.

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…

> 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 bloate…

Discord? Kopete p0wns Discord using 1/16 of the resources.

Re: Maybe people do care about performance and reliability

#213
post #112
post #15

Earlier quoted context omitted.

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

It seems to list a bunch of directories. It is slower on Windows.

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.

Re: Maybe people do care about performance and reliability

#214
From a business point of view, performance and reliability (and code quality) are irrelevant. The most important thing is that the product has a market to explore. We can see this in many products.

I've been working with software since 1999, I've never seen any developer or manager worry about performance. I've seen a religious battle over formatting or using a Java library, or "it's not the Ruby way".

I never participated in any performance or reliability meetings, or projects, or religious battles.

In general, performance is only fixed in very extreme cases. For example, I worked on fixing code that generated a few megabytes of SQL. Or code that uses all of the server's memory.

And it's hard to get permission to fix some extreme bugs. The code that generates a million stored procedures after a few months still exists at one of the places where I worked.

At another company, I fixed a problem (infinite printing) that had been around for 20 years (I even made a birthday cake for the bug), under pressure from the biggest customer who couldn't use a report and no workarounds worked anymore. 20 years of workarounds.

You are sometimes seen as a radical if you try to fix the most absurd bugs. Today I document the bug and wait for the prioritization. Sometimes you fix it after 20 years...

Re: Maybe people do care about performance and reliability

#215
post #94

Earlier quoted context omitted.

> 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 br…

Having worked both sides of this, it's generally the case that IT is absolutely terrible at their job that ends up with them getting called in late.

Sounds like a good reason to bring them in even earlier

Re: Maybe people do care about performance and reliability

#216
post #71

Earlier quoted context omitted.

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

CorelDRAW 8 came out in 1998. That it even runs on a 486 is a miracle.

Lots of peple used 486s back them. Even in 2003, lynx and gv/xv/mpg123 were perfectly usable on a FreeBSD desktop with FVWM.

If it had 16MB of RAM, or 32, it could run better. A 486DX133 would be fine.

Re: Maybe people do care about performance and reliability

#217
post #5

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.

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

Re: Maybe people do care about performance and reliability

#218

The author says that he's not a product manager and doesn't have a particular insight. As a PM, I can share how I think: The main question is "does it matter?" The answer depends case by case. For example, if I am the PM for TurboTax Premier desktop software, I know that it's latent - but it probably doesn't matter in a way that deserves prioritization. Sure, my clients would like for the forms to load faster, but th…

Anecdotally, I stopped using TurboTax (after using it for 8 years) for 2 reasons. I was never confident that my tax situation was being handled correctly. The UI is noisy, the explanations don't explain. So I would buy audit insurance just in case. The second reason, it was slow and navigating between pages and sections was annoying. So now I pay a real person to do my taxes. It takes a quarter of the time, costs abo…

If you're not self-employed there's like a 0% chance you're getting your taxes wrong by holding TurboTax wrong.

If you're FAANG there is some chance you're overpaying by not doing the RSU cost basis properly.

Re: Maybe people do care about performance and reliability

#219
post #142

Earlier quoted context omitted.

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.

Re: Maybe people do care about performance and reliability

#220

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 a…

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 s…

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.

Post reply on HN