When I was younger, I always wanted the perfect solution to an IT problem. I remember getting into argument after argument trying to insist upon the perfect configuration, setup, or whatever it was to meet the need.
The problem with looking for the perfect solution is that there are a lot of considerations that aren’t taken into account. These things apply not only to the problem at hand, but broader. Let’s look at some of them:
- The overall cost in money
- The amount of human effort it will take to get it implemented.
- The timeline it will take to implement.
- The complexity it introduces to the environment.
One issue that we encounter when insisting on the perfect solution is we bypass the good enough solutions. And often times the work and cost difference between good enough and perfect is substantial. By focusing on perfect, we end up committing people whom can be used elsewhere far longer than a good enough solution. we end up spending more money. In short, we reduce overall what the organization can get accomplished.
When we focus on perfect vs. good enough, we also potentially violate lean and agile principles. Lean and agile would indicate we get a minimum solution together as quickly as possible for feedback, for testing, for learning information we didn’t know we needed. From that initial offering, we get the knowledge we need to improve. And by iterating quickly, we end up developing the solution the user needs, not the one we had in our heads.
And that points out another issue with perfect solutions. They are perfect based on what we know at that point in time. But we don’t know what we don’t know. What we may envision as a perfect solution may be far away from is the best solution. We just don’t have the information to see that. Therefore, it’s not good to focus on the perfect. It’s the perfect based on incomplete information. And the perfect is the perfect enemy to architecture.