Some software bloat is OK

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.

I've found that mentioning bloat is the fastest way to turn a technical conversation hostile.

Do we need a dozen components of half a million lines each maintained by a separate team for the hotdesk reservation page? I'm not sure, but I'm definitely not willing to endure the conversation that would follow from asking.

I've never interpreted "Premature optimization..." to mean don't think about performance, just that you don't have to actually implement mechanisms to increase performance until you actually have requirements to do so - you should always ask of a design "how could I make this perform better if I had to".

To me, it rather meant: "Ultrahard" optimization is perfectly fine and a good idea, but not before it has become clear that the requirements won't change anymore (because highly optimized code is very often much harder to change to include additional requirements).

Any different interpretation in my opinion leads to slow, overbloated software.

Yeah - I've heard that described as "It's easier to make working things fast than fast thing work" - or something like that.

It is forever baffling to me that so many devs don’t seem to appreciate that small performance issues compound, especially when they’re in a hot path, and have dependent calls.

Databases in particular, since that’s my job. “This query runs in 2 msec, it’s fast enough.” OK, but it gets called 10x per flow because the ORM is absurdly stupid; if you cut it down by 500 microseconds, you’d save 5 msec. Or if you’d make the ORM behave, you could save 18 msec, plus the RTT for each query you neglected to account for.

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

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.

What I once said to a less experienced developer in a code review is:

> Don't write stupid slow code

The context was that they wrote a double-lookup in a dictionary, and I was encouraging them to get into the habit of only doing a single lookup.

Naively, one could argue that I was proposing a premature optimization; but the point was that we should develop habits where we choose the more efficient route when it adds no cost to our workflow and keeps code just as readable.

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.

Yeah, one of my pet hates it to get to the end of a project that is running slowly, and when you profile you find there is no smoking gun, just thousands and thousands of tiny paper cuts.