Around 2000-2001, the Pragmatic Programmers introduced me to this term. At the time, I took it to mean doing just enough design to get your feature working. I didn't really take to heart the longer-term trade-offs that lingered around, including technical debt.
- Extremely poor quality slows us down. Striving for perfection also slows us down. We need to find the sweet-spot somewhere short of perfection, where we are not slowed by neither defects nor perfection.
- We need to design towards perfection on the more important, more valuable parts of the system. Here, value is what the customer perceives, or areas of code where we spend much of our time and cannot afford slow development.
- We should back away from perfection, and spend less time designing the areas of the software that are not as critical.
- These decisions should be based on the value of the features we are developing, and on how much the design gets in the way of future work.
There is alot of subtlety here, and getting good at this comes with mistakes and experience.