Ready is Better Than Ideal: Embracing “Good Enough” in an Imperfect World
It’s Philosophical Wednesday, and today we’re tackling a fundamental truth that’s easy to say but harder to live by: ready is better than perfect. This isn’t some new revelation I’ve stumbled upon; it’s an obvious principle. Yet, a lot of engineers, and especially many people from academia, struggle with this. The reality is, we don’t live in a perfect world, unfortunately, and we probably never will.
When we’re building something — be it code, a system, or an architecture — there’s this persistent temptation to craft something idealistic, something perfect. But the hard truth is, nobody needs it in that idealized form. Now, let me be clear: I’m not saying nobody needs clean and good code. That would be a lie, and frankly, a topic for a separate video. I’ve witnessed countless cases in startups where they paid millions to fix scalability problems because the engineering was weak. So, quality absolutely still matters. However, the crucial point is finding the balance.
This need for balance extends beyond our professional lives; we need to keep this balance in simply living in an imperfect world. This brings to mind the Japanese philosophy of Wabi-Sabi. I really like this concept — it finds beauty in things that get older, things that get used, and inherently, things that have imperfection. It doesn’t mean you should love broken things, but it does mean you should be okay with something that maybe isn’t ideal.
So, if we’re talking about architecture and engineering solutions, what should be the main driver? First and foremost, it’s the requirements and the concept of “good enough.” For me, “good enough” means it’s working and doing the stuff that people want to have at this stage. A solution that is working is much, much better than an ideal one that’s still on the drawing board.
Think about the fast-paced world of knowledge graphs and artificial intelligence agents. Every week there’s a new paper, a new architecture. We simply cannot rewrite everything from scratch just because someone, right now, invented a slightly different take on cognitive processes. We definitely need to use our resources wisely and understand what kind of benefits we will actually get. Moreover, we can’t always wait for big industry to adopt something that we might ideally want. For example, I blog a lot about dependent type theory or simple type theory with quasi-dependent types for graph modeling. These are powerful, but we don’t have the widespread solutions yet. That’s why we can’t always use them. Maybe TerminusDB is a good example that uses dependent type theory, but it’s still evolving, it’s not fully “ready” for every scenario. That’s why we need to use something that is more adopted by current tools, something that is working even if it’s not ideal.
This is life. Engineers always work with imperfection and incompleteness. It’s a big mental thing just to accept it and allow yourself to live in this imperfect world, and to be imperfect also. But, and this is critical, you also need to find that edge where you do need to care about this stuff, because neglecting it could derail the whole path.
I know it’s simple, but people quite often forget about these simple things, and that’s the problem. We try to make things too complex because we sometimes overthink, sometimes over-plan. That’s why we need to talk with the business all the time. We need to refine the requirements and understand what “good enough” means, what “working” means, and where the focus actually is. Because if you rely just on engineers, yeah, they will often want to create some perfect, ivory tower solutions, and that’s not the path to survival, for sure.
So, remember, ready is better than ideal. It’s about embracing the functional, the “good enough” architecture that serves the present need, and finding the Wabi-Sabi beauty in our imperfect, yet working, creations.
See you next time, and choose wisely.
