Many software developers are overly sensitive to performance and spend a lot of
time and effort considering the performance of their code design. While I
understand their concerns and that they don’t want to be negligent, their
efforts are generally inefficient and sometimes misguided.
Performance bottlenecks are commonly not where you would have expected them to
be. A lot of upfront effort can be wasted on poor assumptions and planning.
Many respond to this argument by doing even more preemptive optimization design
and planning, so as to correctly identify the bottleneck. This is rarely as
efficient as simply implementing the original feature, profiling it, and then
tune or address the actual bottlenecks.
There are certain contexts where some preemptive optimization is appropriate,
such as network drivers or low-level protocol implementations. But in the
majority of cases, there is no need. Overall, the balance of concern is wrong,
in my opinion. Some advance thought for performance, so long as it doesn’t
disrupt your progress, probably won’t impact productivity much.
Unfortunately, I’ve been in many conversations where someone played the
“performance card” and derailed any discussion or progress while that tangent
had to be addressed. This is an example of a larger, more troubling problem in
software development.
There are many areas of presumed conventional wisdom than
few are willing to challenge. This combined with the typical myopia most
developers experience, whereas they see the problem they want to solve as
opposed to the one that is there, is one of the main risks to success for
software projects. Also, if the conventional wisdom and status quo was so
correct in software, why are there so many failed projects, blown schedules and
budgets, and quality and sustainability problems in the software industry?
About the Author
