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.
Maybe people do care about performance and reliability
191–200 of 280 posts
Re: Maybe people do care about performance and reliability
#192Earlier 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?
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
#193Earlier 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 "…
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
#194Earlier 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…
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
#195Earlier 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…
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
#196Earlier 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?
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
#197The 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…
Re: Maybe people do care about performance and reliability
#198Earlier 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…
Re: Maybe people do care about performance and reliability
#199Earlier 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…
The UX of those phones was pretty poor though.
[0] - SyncML.
Re: Maybe people do care about performance and reliability
#200Earlier 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.