Is “Good Enough” Too Good?

Paul Ramsey recently wrote an interesting post about how “good enough” is plenty “good enough” when it comes to data structures and performance in PostGIS. In another bit of serendipity, I’d had this post half written with the same title, though for entirely different, but in a way related, reasons. So Paul, pardon the sincere flattery, but here goes (altered title and all).

For many years at Safe, Don and I have preached the mantra that “good enough” is NOT “good enough” when it comes to our products. If we says we are going to be fast, then we better be really fast, not just a bit fast. If we say we are going to convert coordinate systems, then we better do it with excellence. And we would apply this mantra with the same vigor as my sons do when spreading honey onto their toast – indiscriminately, thickly, covering all aspects of our product to the best of our ability so long as we still had enough honey (programmer resources) to spread.

But recently Don and I were at a conference where one of the speakers gave a strong argument that “good enough” is likely harmful – it might be too good if you are spreading the honey where it does not really give your product a clear differentiation from the pack. By spreading your honey on the crusty part that you might not eat anyway, you are depriving the main part of your toast from all of the honey that it deserves. So if you are making a product, you had better figure out what its main differentiating point is, pour the effort (honey) into it, and be ruthless about everything else that only needs to be barely good enough.

So if you are making a product, you had better figure out what its main differentiating point is, pour the effort (honey) into it, and be ruthless about everything else that only needs to be barely good enough.

Yikes. It goes against my personal drive not to do everything with excellence, but there is undeniable wisdom here.

Yikes. It goes against my personal drive not to do everything with excellence, but there is undeniable wisdom here. So what does it mean for Safe? Maybe it means if we think that data inspection is not really our big value to customers, we should not spend any more than the most minimal amount of time on that aspect of our product. So goodbye FME Data Inspector? Alas, we barely knew you! (For the record, I do not think that is the right answer).

While at Autodesk University this week, I talked with a long time customer (and fan) and proudly announced how much faster FME 2009 was than FME 2008, and how we are on track to be even faster with FME 2010. His response – speed was never our problem. FME has always exceeded his expectations for performance. Yikes again. Maybe we should not be worrying so much about performance. (Again, I do not agree).

So, what do you think? If we are to focus on “more important” things, are there any obvious bits of “crust” in FME that are not deserving of more honey? As you can see from this post, the perfectionist in me has a hard time seeing anything obvious, but maybe that is because I kind of like the crust…