Re: Premature optimization

[clintp]

I've acted as project manager (and lead developer) for quite a few projects that were user-oriented. Some were web apps, some were client/server database query apps, etc.. All tend to be multiperson teams with hundreds of thousands of lines of code, and development time spanning months.

Usually a rough working prototype is constructed -- even if it's just a first pass at one of the screens. Slapped together in a fraction of the time it takes to complete the app, I try to get the performance to within half an order of magnitude that the final application needs to perform.

If my team can get the app to work in 5 seconds where a 1-second response time is needed -- that's great. We discuss the potential points of optimization (there's always some) and then we start to code using that design without the optimizations. The person assigned to the code where the handwaving took place is given some idea of what will be done ("this will be memoized/cached", "just code this query the way it is, we've got something better later", "we've got a clever hack for this, don't sweat it now") but is told to code it in the most straightforward way possible for debugging and unit testing.

Near the end of a project, sure we'll go back and tweak the application to get every ounce of speed. By then the hardware's been upgraded, the libraries have improved, we've found the flaws in the design, and most of the code's been debugged. But in the beginning, this is generally what I do and it hasn't failed yet.