Home > technical > Premature Optimization And Simplification

Premature Optimization And Simplification

Premature optimization is the root of all evil – Donald Knuth

Most, if not all software developers will nod their heads in agreement with this technical proverb. However, as you may have personally experienced, one man’s premature optimization is another man’s simplification. Some people, especially BMs and BMWs shackled from above with a “schedule is king; what is quality?” mindset, will use that unspoken mantra as a powerful weapon (from a well stocked arsenal) to resist any change – all the while espousing “we’re agile and we embrace change“. Lemme give you a hypothetical example.

Assume that you’re working on a project and you discover that you can remove some domain layer code with no impact on the logical correctness of the system’s output. Furthermore, you discover that removal of the code, since it is used many times throughout the BBoM code base, will increase throughput and reduce latency. A win-win situation, right?

The most reliable part in a system is the one that’s not there – because it’s not needed. – Unknown

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery

OK, so:

  1. you disclose your discovery to the domain “experts”,
  2. they whole-heartedly agree and thank you,
  3. you remove the code, and all is well.

Well, think again. Here’s what may happen:

  1. you disclose your discovery to the domain “experts”,
  2. you receive silence (because you’re not a member of the domain layer “experts” guild),
  3. you persist like a gnat until the silence cannot be maintained,
  4. you’re “told” that your proposal is a pre-mature optimization,
  5. you say “WTF?” to yourself, you fire a verbal cruise missile at the domain experts’ bunker, and you move on.

  1. No comments yet.
  1. No trackbacks yet.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.