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…

fmehoney

About Data Collaboration General

Dale Lutz

Dale is the co-founder and VP of Development at Safe Software. After starting his career working spatial data (ranging from icebergs to forest stands) for many years, he and other co-founder, Don Murray, realized the need for a data integration platform like FME. His favourite TV show is Star Trek, which inspired the names for most of the meeting rooms and common areas in the Safe Software office. Dale is always looking to learn more about the data industry and FME users. Find him on Twitter to learn more about what his recent discoveries are!

Comments

6 Responses to “Is “Good Enough” Too Good?”

  1. Rob says:

    You know a lot enjoy the crust! That’s why you have someone mock up an image of FME styled bread and honey, the blog post crust. Keep up the work on performance, and make FME Server sing.

  2. Excellence and perfectionist is good!

  3. tim says:

    I have always thought that a good sandwich starts with good bread, good bread takes time, good ingredients and a quality oven to cook in… fme is a great data oven, lots of tools to spread honey with once I’ve got good bread… don’t forget the bread!

  4. Oliver says:

    An excellent sunday morning breakfast not only consists of bread and honey.
    It needs a lovely layed table with valuable plates and perhaps some flowers.

    FME is honestly the best honey bread I ever ate, but sometimes you forget the trappings like the bill of fare (e.g. documentation, tutorials etc.).

  5. Dale Lutz says:

    I love the food analogies! But Oliver’s comment about the bill are particularly relevant — in the early days of Safe I remember Don and I asking customers that wanted to buy to evaluate a bit longer so that we didn’t have to take time away from programming in order to create an invoice, ship a box, and deposit cheques(!). Not a winning business strategy for the long term you’d think, and undoubtedly violating one of the Ferengi Rules of Acquisition.

    But seriously, the point is well taken. To have an excellent whole product, there are many things outside of the actual technology that have to be a bit better than good enough. Being so close in it is often hard for us to see precisely where and we are always trying to pounce when we have scales removed from our eyes. Ironically enough, just this morning we were discussing plans for a revamped tutorial, for example.

    So thanks for the comments, and don’t hesitate to let us know if we forget to send you a bill sometime!!!

  6. MHabarta says:

    Dale

    I’m a perfectionist too and I am a fan of FME because it is excellent software. I want to say: Keep on doing well what you do.

    I like things which are done well and I have dumped a number of products which fail to work up to the expectations they raise.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts