When someone chooses a poor technical solution, we often assume they lacked knowledge or skill. Sometimes they did. Often they were optimizing for something other than the system.

A few motivations show up regularly:

  1. People avoid blame. A slow, familiar process can feel safer than a faster one. Nobody wants to defend the unusual choice after something breaks.
  2. People protect their roles. They may resist automation or simplification when the current process makes them necessary.
  3. People want to learn. A developer may choose an unfamiliar language or tool because the project gives them a chance to use it.
  4. People build their portfolios. A complicated solution can be more useful to someone’s career than a boring one.
  5. People want interesting work. They may accept extra complexity because they enjoy the problem.
  6. People want to impress others. A visible or sophisticated solution can receive more credit than a simple one.

These motivations can overlap. They also do not make every decision acceptable. The team still has to deal with the cost.

The useful question is: what was this decision actually optimizing for?

Once you know that, the solution may stop looking irrational. It can be rational for the person and still be wrong for the product.