The Perfect System Doesn't Exist

This can simply be summed up as: we're human. Humans aren't perfect and neither is the code we write. At best we can try to enforce checks and balances with CI and git hooks but since things always change, you'll come across some point where you need to make something in limited time and you'll have to compromise

Pretty good article and good points. I want to add a few more based on my experience:

* On the topic of systems changing. The "perfect" system is a moving target. Have you ever encountered an entire module that could be replaced by a library call? The plot twist is that library didn't exist 5 years ago when the code was written. Found an ugly hack that's completely unnecessary? that was written to overcome a system limitation that has since been removed. As time passes, how a "perfect" system looks like changes as well.

* On the topic of never the same implementation, we aren't all experts in everything. Being assigned to a project in a tech you have no knowledge whatsoever is a very humbling experience. You'll make tons of mistakes, and code will be far less than ideal, but it's only with time that you'll get to appreciate (and fix) those.

* On the point of Good > Perfect, there is the topic of diminishing returns and leverage. In the previous two points we either can't or don't know how to write better systems. Sometimes we can and know how to do it, but it's better not to. A while back I wrote a service that's central to our infrastructure. I spent a bit of time making sure code is clean and we have good test coverage. It has been in production a while and it has never caused an issue. Sometimes I look at it and see some obvious faults: interfaces could be tidier, or some code could be cleaner. However I force myself to not spend time fixing it. Why? it isn't a high leverage activity. Rather than spending time polishing a service that works well, I should spend that time fixing open bugs or improving parts of the system that don't work as well. Even if it isn't as satisfying to our ego, the return on investment will be much higher.

I used to think my love of making things orderly and perfect was a boon as a software engineer, where things should be clean and logical - that this was me sticking to high professional standards. But I've come to realize that these OCD tendencies (I realized I had OCD a few years back) are actually a huge setback. I have to actively work to say enough is enough, my text editor, programs, desktop, filesystem layout, etc. is never going to be perfect let alone bug free, and neither will anyone else's code.

A great skill I have been developing as I mature is the ability to look at a seemingly suboptimal implementation I receive and not be appalled by the perceived sub-optimality but rather appreciative of the history that is embedded in the little details. For me, any system producing correct and useful results is perfect under the constraints of its implementation. Even if the developer was not great, someone was great enough to mitigate for it. I have seen many such ugly, perfect systems.

I don't think we'll ever be able to calculate program designs, like having a computer design the theoretically optimal {sorting algorithm, hashmap, SQL engine} for a given processor, for a particular performance criterion (average-case and worst-case performance), out of the exponentially exploding set of possible type and function definitions. And "the perfect system" is different on a DS, a smartphone, a desktop PC, or a GPU or supercomputer. I think it's orders of magnitude more complex than designing an optimal chess algorithm. But I'll look into the PDF you linked, since I believe "calculating a program design" would be great to have (though I doubt it's possible), and people aiming for it will hopefully create useful tools along the way.

I do think we can and should define a self-consistent internal logic for the program designs we do write (eg. under a given set of valid inputs, the program is is memory-safe, is thread-safe, does not produce UB, has program-specific invariants upheld by each function's preconditions and postconditions, and produces correct results with eg. O(n log n) runtime, making O(n) allocations totaling O(n) bytes ever allocated), then verify that the code we write upholds this logic. Every program has an internal logic, correct programs have self-consistent logic, and any holes in the logic are exposed as bugs in the program. And easily understood code makes this logic self-evident to readers.