Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations. Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about “buffer gets” and non-unique indexes and demand attention.
My advice: Don’t give in to the temptation to make your design, or your implementation, perfect! Aim for “good enough” and stop when you’ve achieved it.
What exactly is “good enough,” you might ask? Good enough means that the remaining imperfections do not impact system functionality, maintainability, or performance in any meaningful way. The architecture and design hangs together. The implementation works and meets the performance requirements. Code is clear, concise, and well-documented. Could it be better? Sure, but it is good enough, so stop. Declare victory and move on to the next task.
The search for perfection in design and implementation leads, in my opinion, to over-designed and obfuscated solutions that are, in the end, harder to maintain.
A number of the axioms in this book caution designers to avoid unnecessary abstraction or complexity. Why do we have problems keeping things simple? Because we are seeking the perfect solution! Why else would an architect introduce complexity in a workable solution except to address a perceived imperfection in the simpler design.
Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.
