Code Optimization when speed is not the only goal…

I have worked on many software development projects, both commercial and line of business and every single time I talk about optimization to a developer they always jump to the same conclusion. They think I mean speed of execution. I grant that the majority of the time when people talk about optimization that is what they mean, but it is not 100% of the time correct. Often I care more about the maintainability of an application especially if I know it is destined (or doomed) to morph quite a bit over the next year or so. In these case it is often an application that will be used by employees and many of the standard assumptions do not apply.
Take our Intranet for instance. It is only used by employees and our closest contractors. We use it for tracking customers and projects, for forecasting sales and even timesheets. I don’t care if it is 5% slower, I want it to be adaptable since we are an agile company. I don’t mess with the code every week or even every quarter, but the code is written in such a way that I or any other developer on staff can go in and very quickly add a field or add other features very quickly. We didn’t sacrifice security (that would be unacceptable), but we did forgo the multi tier architechure and stored procedures for parameterized queries. This is a sin in many circles, but if the application’s backend is single use (only one application) then there is much less advantage to all the abstraction. I am sure the arguments will flow down on me now, but I see the same drive for complexity without purpose (real advantage I mean) in the Java world where code portability is everything and yet almost no one ever avails themselves of that costly feature.

The next time someone asks you to optimize something ask them if they mean for performance or maintainability and let the funny stares begin…

9 thoughts on “Code Optimization when speed is not the only goal…”

  1. That does seem to be the most common interpretation. The problem is that it can have multiple meanings and it is important to clarify. Often a 5% reduction in processing time is not worth a 50% harder upgrade.

Comments are closed.