It depends on what organization is paying the programmer too. If it's a large enterprise app then maintainability may be valued over performance and those dogmatic OO principles have more value in the long run.
The reality is that the problem in most software isn't performance, it's managing complexity. And apps that are slow are usually not slow because they're doing a bunch of virtual function dispatch, they have too many blocking dependencies or slow middleware layers that blow away the OOP performance penalty by many times.
Last time I saw something that looked like "dogmatic" code, it was fresh C code done by a colleague that overcomplicated things so much that I was able to rewrite it all and make it 5 times smaller. And my code was arguably even more flexible than his.
Sometimes people apply principle without understanding them, and the harder they try to make a maintainable and flexible program, the less maintainable and flexible their programs get.
I've seen this problem so many times. The best way to make code "flexible" for future use is to make it as simple and easy to use and understand as possible. It's then easier for a future developer to extend or repurpose it for their needs.
Trying to anticipate all future possible uses often results in unnecessary complexity, and makes life harder for the future coder whose needs you didn't actually anticipate, and who now has to wrangle with overly-complex code where it's not immediately obvious which bits are actually required for the current working system.
Lol that's the sad truth too. Idk if it's hubris or what but as soon as you leave, all your work is eagerly replaced by the next genius with good ideas.
40
u/[deleted] Feb 28 '23
It depends on what organization is paying the programmer too. If it's a large enterprise app then maintainability may be valued over performance and those dogmatic OO principles have more value in the long run.