One of the hardest things for us nerds to stop doing is maxing out favourite aspects of our work. For example, I used to work for a team leader who would carefully calculate the run-time efficiency of every algorithm he wrote or he asked someone else to write. Endless discussions were held to decide if framework X’s sort algorithm could be trusted to sort those ten entries into alphabetical order. Another person I worked with would tinker endlessly with control layout on dialog boxes and create complex formulae for others to use to ensure consistency of controls, labels, grouping boxes, tabs, etc.
Of course, while this was going on, the customer just wanted a simple dialog box that displayed the names of their contacts in alphabetical order.
I think what happended here is that the leaders of these projects (and almost every other project I’ve worked on) didn’t create a shared view of perfection. They allowed the nerds, who all have their own peccadillos, to decide how much needed to be done. Instead they should have outlined their own view of perfection (using the idea of tradeoffs I’ve talked about before) and made it clear that a “balanced good-enough is perfect”. An ugly, misalinged dialog box isn’t good enough and neither is a super-expensive beautifully laid out dialog.
Good enough is the new perfect. This is one of the less explicit, but still important, messages that has come from agile software development. Maxing out a few aspects of our work is a way of selling our customers and projects short. We need to acknowledge that all aspects need to be collectively maximised and that this generally requires no aspect to be individually perfect.
Perfection is the enemy of the good.