Wasn’t it Knuth who said that “Premature optimization is the root of evil”?
Antipattern name: System-Idle Optimization
Also known as: Premature optimization
Most frequent scale: Individual developer.
Refactored solution: Reduce complexity by implementing a simpler solution that works when the system is idle and is still efficient when it is really busy.
Root causes: Not being able to look at a system from the outside and determine which actors/stakeholders would actually benefit from the optimization. Low level focus.
Unbalanced forces: Low level technical competence, lack of system overview.
Anecdotal evidence: “It is clear that this is a performance problem ”
A developer, usually a technically competent one, designs a piece of software without any technical overview and creates optimizations just for the “design fun” of it. The design is supposed to be more efficient without however
doing any computations or measurements.
When thinking about the different actors and stakeholders involved (e.g. administrator, end-user, developer, project manager, product manager), it becomes clear that most actors/stakeholders do not observe any change as a result of the optimizations, except of course for the project manager who sees additional costs both for development and maintenance.
Strikingly, in many cases the software has some true performance problems that can only be found by looking at the system behavior as a whole. In other words, the effort to optimize performance was totally misdirected.
Some examples:
- A system that tries to create the services it exposes at runtime on demand, usually defended by the idea that this would be more efficient. Nevertheless, during the lifetime of the system all services will certainly be used so in effect the solution does not really optimize anything. The only thing it does is postpone errors in services until a point in time until they are first used which can be long after deployment. And would that be an advantage? Guess not!
- A system that uses thread pools and aggresively tries to keep the number of threads minimal at runtime, saving memory and resources. Of course, only saving memory and resources when the system has almost nothing to do, and ensuring that additional resources are used for creating these resources again once they are needed. Not to mention of course the additional complexity involved in comparison to a thread pool of fixed size.