Comments on: Optimize Late, Benchmark Early

By: mccoyn

mccoyn — Mon, 26 Nov 2007 19:52:19 +0000

The only time I’ll optimize early is when the implementation is so slow that it bothers me while I’m testing or debugging. In other words, when it is blatantly obvious that it will be a problem.

Optimizations have a habit of making code more complicated. Optimizing feature A might take one hour and add 30 minutes to the time to implement feature B later, so its better to implement feature B before optimizing feature A. Also, it is better to never optimize feature A if you can get away with it (thus benchmark before optimize.)

By: Hans-Eric

Hans-Eric — Sat, 24 Nov 2007 08:54:08 +0000

Paul, you’re the kind of developer I’d love to work with.

By: Paul W. Homer

Paul W. Homer — Fri, 23 Nov 2007 20:07:05 +0000

For me, I use the architecture to draw ‘lines’ in the system, partitioning it into lots of smaller pieces. When I build the initial version, I tend towards overly simple implementations for all of the pieces.

In later iterations — depending on need — I usually start upgrading the models, algorithms or interfaces to accommodate more efficient or expanded versions of the components. I don’t like to go straight into the optimized version mostly because I often don’t fully understand the problem domain until I’ve seen the code run in a real environment for a while. If I am wrong in my initial understanding, optimizing wastes a lot of valuable time.

Typically, in the early years that generally leaves parts of the system as being very crude, while other parts have been significantly enhanced. That’s ok, and not a bad way of dealing with limited time. It all depends on the external factors in the project; politics frequently overrides technical requirements.

Paul.