Week #3 of the SEP Blog Battle.
Read about it here.
Follow us on twitter.
Many times, I’ve heard the cliche – perfect is the enemy of good enough. I agree with this, for some definitions of the phrase “good enough”. But that definition changes for me.
How do you define good enough? My guess is that it depends. It likely depends on your current problem, project, client, or more.
While I agree that aiming for perfection isn’t ideal – it’s likely not efficient, it likely is over engineered for the current problem, and it is likely going to take more time than it needs to. However, I don’t believe that we can define what “good enough” for the full product looks like on day 1. The reality is, we aren’t going to build out 28 web services because we need to write 1 service to return a data set. You can’t even plan what the perfect web services would look like.
This doesn’t mean that you can simply hack something together and effectively under-engineer a solution. Instead, converge on what is “good enough” for your current, self-contained, problem. While implementing your “good enough” solution, use good practices, be heedful, and use design principles.
As you build this product, you will (hopefully) iterate often. Each time you iterate, your definition of “good enough” will change. Your design will evolve as you iterate.
Instead of taking bets on what is “good enough”, plan on evolving your design.
