Perfection is not over-engineering

In online discussions people always blame „lazy developers „ like there would be no product owners, testers, business analysts, scrum masters etc.

I think this is a bit of a generous reframing of what seeking perfection is. Generally I think perfection seeking is best described as over-focusing on the details and pre-planning instead of laying a general blueprint that leaves room for pivots, future decisions, and iteration along the way. There's a whole breed of engineers that are really great thinkers but get stuck in the mud trying to pre-think the best way to do something instead of being adaptable.

> Over-engineering is solving the wrong problem. That's the whole definition.

Wholeheartedly disagree. Over-engineering already seems pretty well defined just based on the words alone without tacking on a strange arbitrary definition to suit your blog post, but I think most people most people would define it more as "spending too much time and/or resources to solve a problem more-thoroughly than necessary".

Suppose I was given the task to convert all the JPEG images in a folder to PNG.

Solution A) I could write a highly optimized program writing custom CUDA decoders and encoders and using Open MPI for CPU-based optimization, and create an elaborate plugin framework on top of this to make this modular and cool.

Solution B) I could just run `find -name "*.jpg" | parallel magick {} {.}.png`.

Both solve the "right" problem; the ask was to convert these images, and both approaches can absolutely do that, so they didn't solve the "wrong problem", but I would argue that for most people Solution A would be "over engineered". You could argue that by building custom encoders and decoders and the like we're solving the "wrong problem" by going beyond what the problem asked for, but I feel like if you're criticizing the engineering methodology then that kind of proves my point.

We generally think someone is "over engineering" primarily when we are happy with the low-effort result.

There are times when Solution A is the right way to go about it. Maybe you want something that takes advantage of custom hardware, or maybe you can make an assumption about these images that Imagemagick can't, or maybe you really just understand image encoding significantly better than the Imagemagick people. in those cases, we generally don't consider it "over-engineering".

The article seems too focused on over-engineering.

Achieving 100% is often much much harder than, say, 95% or so. Just good enough. This is the old "Worse is better" problem. Why did Linux outcompete, say, Minix or something else? Worse is better is a more practical focus. You don't need to achieve 100% perfect per se. Momentum is often more important. You can still have a lot of efficiency if the momentum is the main driver.

https://en.wikipedia.org/wiki/Worse_is_better

Perfection is nice in theory; in practice it will be whacked into submission by the worse-is-better speedy wizards. The hobo programmers built for speed. You make fun of them. Then the top 500 supercomputers all use what they wrote ... like Gandhi they were winning.