[aljgz]

In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm.

Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong.

I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especially so when the error has created data that's stored somewhere we might not have access to. But even more so, when the harm has reached the real world.

[anymouse123456]

I don't believe there is any tension at all between fast and simple software.

We can and should have both.

This is a fraud, made up by midwits to justify their leaning towers of abstraction.

[embedding-shape]

User-facing, sure, nothing stopping us from doing "simple and fast" software. But when it comes to the code, design and architecture, "simple" is often at odds with "fast", and also "secure". Once you need something to be fast and secure, it often leads to a less simple design, because now you care about more things, it's kind of hard to avoid.

[ndriscoll]

IME doing application servers and firmware my whole career, simple and fast are usually the same thing, and "simple secure" is usually better security posture than "complex secure".

[embedding-shape]

Interesting, never done firmware, but plenty of backends and frontends. Besides the whole "do less and things get faster", I can't think of a single case where "simple" and "fast" is the same thing.

And I'd agree that "simple secure" is better than "complex secure" but you're kind of side-stepping what I said, what about "not secure at all", wouldn't that lead to simpler code? Usually does for me, especially if you have to pile it on top of something that is already not so secure, but even when taking it into account when designing from ground up.

[ndriscoll]

Not really. `return 0` is the simplest program you could write, but it's not terribly useful. There's an underlying assumption that there's some purpose/requirement for the program to exist. Through that lens "secure" is just assumed as a requirement, and the simplest way to meet your requirements will usually still give you the fastest program too.

"Do less and things get faster" is a very wide class of fixes. e.g. you could do tons of per-packet decision making millions of times per second for routing and security policies, or you could realize the answer changes slowly in time, and move that to upfront work, separating your control vs data processing, and generally making it easier to understand. Or you could build your logic into your addressing/subnets and turn it into a simple mask and small table lookup. So your entire logic gets boiled down to a table (incidentally why I can't understand why people say ipv6 is complex. Try using ipv4! Having more bits for addresses is awesome!).

[anymouse123456]

Same experience here and even more powerfully illustrated in firmware development.

[MyHonestOpinon]

> "simple" is often at odds with "fast"

Sort of. But if you keep the software simple, then it is easier to optimize the bottlenecks. You don't really need to make everything complicated to make it faster, just a few well selected places need to be refactored.

[gspr]

> I have seen more benefit from it than harm.

Same. I, too, am sick of bloated code. But I use the quote as a reminder to myself: "look, the fact that you could spend the rest of the workday making this function run in linear instead of quadratic time doesn't mean you should – you have so many other tasks to tackle that it's better that you leave the suboptimal-but-obviously-correct implementation of this one little piece as-is for now, and return to it later if you need to".

[anymouse123456]

That is a great example of when the original quote works as intended.

I'm reacting to experiences where the software that emerges from a relatively large team effort can't really be made meaningfully faster because there are millions of tiny performance cuts - from the root to the fruit.

[FarmerPotato]

yes! See Rule 4

/* If we can cache this partial result, and guarantee that the cache stays coherent across updates, then average response time will converge on O(log N) instead of O(N). But first make the response pass all the unit tests today */