←back to thread

Some software bloat is OK

(waspdev.com)
50 points senfiaj | 2 comments | 04 Nov 25 08:27 UTC | HN request time: 0s | source
Show context
Grumbledour ◴[04 Nov 25 09:46 UTC] No.45809114[source]▶
The question is of course always where someone draws the line, and thats part of the problem.

Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.

And while they might be right concerning small stuff, this often piles up and in the end, because you choose several times not to optimize, your technology choices and architecture decisions add up to a bloated mess anyway that can't be salvaged.

Like, when you choose a web framework for a desktop app, install size, memory footprint, slower performance etc. might not matter looked at individually, but in the end it all might easily add up and your solution might just suck without much benefit to you. Pragmatism seems to be the hardest to learn for most developers and so many solutions get blown out of proportion instantly.

replies(5): >>45809233 #>>45809261 #>>45810859 #>>45811105 #>>45814838 #
ndiddy ◴[04 Nov 25 13:59 UTC] No.45811105[source]▶
> Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.

Yeah I find it frustrating how many people interpret that quote as "don't bother optimizing your software". Here's the quote in context from the paper it comes from:

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

> Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

Knuth isn't saying "don't bother optimizing", he's saying "don't bother optimizing before you profile your code". These are two very different points.

replies(1): >>45811654 #
1. WBrentWilliams ◴[04 Nov 25 14:51 UTC] No.45811654[source]▶
I'm old.

My boss (and mentor) from 25 years ago told me to think of the problems I was solving with a 3-step path:

1. Get a solution working

2. Make the solution correct

3. Make the solution efficient

Most importantly, he emphasizes that the work must be done in that order. I've taken that everywhere with me.

I think one of the problems is that quite often, due to business pressure to ship, step 3 is simply skipped. Often, software is shipped half-way through step 2 -- software that is at best partially correct.

The pushes the problem down to the user, who might be building a system around the shipped code. This compounds the problem of software bloat, as all the gaps have to be bridged.

replies(1): >>45815506 #
2. jay_kyburz ◴[04 Nov 25 20:26 UTC] No.45815506[source]▶
I've found that sometimes if you start 1. without even considering 3. it can be significant amounts of work to go back and restructure. Especially if in doing 3. is a fairly big change that results in lots of QA.

So for example, we have a lot of code that just does some work every render frame, when really it should only do that work when values change. Whats worse is that, every frame, the code queries parameters that are accessors in c# which in turn do heaps more work.

I had to fix a lot of these kinds of things when trying to do get our game to work on the Nintendo Switch.