lack of requirements responsible for pre-mature optimizations

Yesterday I presented my 1 day performance tuning seminar to a group in the Netherlands. They were an every engaging group and they sparked some very interesting discussions. One was regarding the old adage of pre-mature optimizations. The mantra is; make it work then make it fast. Though I do think that you do have to consider performance up front, it is advice that can't be ignored. I can cite numerous cases where people were trying to get code to run very fast before they actually had it functional. However I can also say that in just about every one of these cases the developer was lacking in requirements that would have helped him decide wether or not the optimization was premature or necessary.

For example, bubble sort is O(N^2) where as quicksort is O(nlogn). So obviously quicksort is much faster right? Well it depends, if you've got a small number of things doing a bubble sort will be quicker. The question is; do you have enough information in the form of requirements to know if the simple bubble sort is good enough for you're going to need to resort to the more complex quicksort. If you do have enough information then maybe coding up the quicksort isn't a premature optimization. If you don't have enough information then I'd have to say that it is. In either case it behooves you to isolate the sorting away from the rest of the application so that when you finally do get real requirements you can make it fast, if it isn't already fast enough.

tags: premature  optimization  java  performance