Good enough software

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.

Fast-forward to the spring of 2010...I've run across some great articles by Ron Jeffries and Josh Kerievsky addressing this topic, and framing it against product value and productivity.

Take-aways:

• 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.