[Hardliner66]

Even tho I'll get flak for it, I'll call bs on the article.

It's the same as the phrase "(premature) optimization is the root of all evil". Does it mean you should never optimize? No. Does it mean you should always optimize as a last step? Also no.

Here's the full quote: "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%."

It's way more nuanced and basically says: "Stop wasting time on optimizations with little gain, but still do them where they are useful/necessary."

Right now I'm working on an embedded device running a small Linux. Our resource usage is well within the bounds, so thinking about better architectures or optimizations is an imaginary problem. Right? No. Not at all. Making our software smaller and/or faster doesn't only mean we can put on more software, it also means we could produce cheaper because we need less resources.

Thinking about and experimenting with different architectures or newer technologies also seems like imaginary problem solving at first, but there is a good possibility that you improve your system as well. A better architecture could make your software more maintainable or give you the flexibility to implement new features in a way, that was really cumbersome with the old code.

So while I agree with the sentiment that you should not implement things you don't need, I also think that there should be room for people to experiment and try out different things. Because sometimes, the people working with the code the longest are blind to it's many shortcomings. Because it's normal for them to just work around them. But getting rid of those shortcomings can save you hundreds of man hours of work in the long run.

To cut a long story short: Do experiment. Do think about problems you might have in the future. Do the mental exercise and think about how to improve your current code and architecture. But don't blindly implement it

Always evaluate what your trying to do. Check if it improves the things it's supposed to improve and also check if it doesn't make matters worse elsewhere. Get to know the tradeoffs and make informed decisions if changing something that works to something that's better is worth it to you.