We've all been there, a problem or feature presents itself that we can see a mile away will need rework or have scope creep. We'd love to take the time to ascertain every outlier, scope out extensibility and plan for seamless future maintainability. However the project deadline beckons, now the choice has to be made. Does perfect get in the way of good? How much time can be sacrificed at the altar of a feature that may never be touched again?
My personal mantra since being introduced to it by a team lead years ago, mostly due to not following it crippling my productivity more times than I care to count.
Don't let perfect get in the way of good.
There will always be a better solution, always some way to refactor, always some way to be more extensible, more documented... always something else. Just like there will always be another feature, another bug, another system, another framework. Always more to do, yet time waits for no one. Don't get me wrong the requirements for things should 100% have time spent to fully flesh out the scope and requirements, but the execution for every change doesn't need a full architectural scoping session and systems design case study.
A rudimentary feature that works can be functional in production for years without it ever being a concern. Fancy code doesn't always mean the best code. When you start coming up against issues of keeping your code maintainable or truely nightmarish to explain to new team members. That's when you need to sit down and have a good look at the bottle necks & pain points of your codebase. But trying to be overly fancy just to save a bit of time later at the expense of missing deadlines or worse still never releasing at all...what is really the worse outcome there?