Live data from Hacker News

Maybe people do care about performance and reliability

buttondown.email

191–200 of 280 posts

Re: Maybe people do care about performance and reliability

#191

Earlier quoted context omitted.

unless you are very, very lucky - dream on

The world is changed by unreasonable people with dreams. So yes, I will. Thank you.

i would say it is changed by reasonable people with a plan

Re: Maybe people do care about performance and reliability

#192

Earlier quoted context omitted.

All good questions, asked by all the devs here. I'm not about to defend the use of this particular product. I was just pointing to an example of FOSS that not only isn't free, it's very expensive.

sorry, but i really can't believe this. to start with how can foss manage a per seat license? i get needing support, but if you have the code (which you must else it is not foss) why can't you strip out the per seat code (which is a no-no in my experience on closed code) and just pay a one-off/per problem support contract?

We could, of course. But it would be a license violation and legal wouldn't stand for it. We can each use it without charge for our own, personal purposes, of course -- just not for the company's purposes.

I can't help you with your disbelief, but it is true that nothing in the FOSS philosophy prevents companies from charging for their work.

Re: Maybe people do care about performance and reliability

#193

Earlier quoted context omitted.

The tax software situation you're describing sounds totally reasonable, but it does seem indicative of a shortcoming in the market. Like, is there really a fundamental reason why the same feature set couldn't possibly be developed while also being faster for customers and not requiring more developer resources per feature? In some cases I could see that being the case: if the core task fundamentally requires signific…

// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." (I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid. For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "…

> Is that technical debt? ... So I would say that's not really a tech debt, just a technical tradeoff that was made.

Well, I'd still call that technical debt. All debt is a tradeoff, and sometimes debt is worth it (or, at least, is judged to be worth it at the time the debt is taken on). In this case, it might be deemed worth it, and reasonably so, especially if there simply aren't enough competitors that this would make a difference at the margin, or if it's simply not feasible for any competitor to implement that same feature in the same time frame with the same amount of developer resources and make it perform faster.

Re: Maybe people do care about performance and reliability

#194

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…

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?

Re: Maybe people do care about performance and reliability

#195

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…

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

Now all apps are ugly and unpolished

Re: Maybe people do care about performance and reliability

#196

Earlier quoted context omitted.

> at least for websites We could start by stopping using these stupid pointless frameworks that provide little functionality but reams of overhead.

How much of it is frameworks like React vs boatloads of trackers and other ad-related stuff?

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

Re: Maybe people do care about performance and reliability

#197

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 about the same as TurboTax + audit insurance, and now I now longer stress about taxes.

Re: Maybe people do care about performance and reliability

#198
post #88
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.

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. So my muscle memory is a lot of ctrl-a, c. [1] A mistake that Chrome adopted afterward a…

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.

Re: Maybe people do care about performance and reliability

#199

Earlier quoted context omitted.

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

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

Re: Maybe people do care about performance and reliability

#200

Earlier quoted context omitted.

sorry, but i really can't believe this. to start with how can foss manage a per seat license? i get needing support, but if you have the code (which you must else it is not foss) why can't you strip out the per seat code (which is a no-no in my experience on closed code) and just pay a one-off/per problem support contract?

We could, of course. But it would be a license violation and legal wouldn't stand for it. We can each use it without charge for our own, personal purposes, of course -- just not for the company's purposes. I can't help you with your disbelief, but it is true that nothing in the FOSS philosophy prevents companies from charging for their work.

of course, you know your business far better than i do. and as you say nothing stops people making money off foss - i've done it myself. but the normal route for this is via people finding the software useful,consultancy, support and adding paid-for features. i have never, ever seen per-seat licenses for foss software. if this software actually exists, you could at least point to its web page.
Post reply on HN