There is always a trade off

One thing that I have learned in 25 years of experience working in software development is that there is always a trade-off for any decision.

Do you need to make an algorithm highly performant? Then you may need to make some sacrifices in maintainability and readability.

Do you need to make the architecture of a software system extremely flexible and resilient to change? Then you may need to make the architecture more complex.

Do you need to use a framework that is a great fit for solving specific business need? Then you may need to accept the performance overhead of the framework in order to receive the gains you will receive in other places.

Do you disagree with other developers on how to solve a problem because you know a better solution? Is it worth delaying the project and causing potential morale issues to get your way? Sometimes, when the consequences are not significant, you need to let a good enough solution win out over a better one.

There is always a trade-off.

The strange thing about that sentence is how many people refuse to acknowledge it. Either though a dogmatic love of a language, programming paradigm, framework, language structure like a case statement, or whatever the case may be.

Dogmatism is dangerous to software development. Why? Because there is always a trade-off, and dogmatism hates trade-offs.

So, how do we deal with the trade-offs?

The good news is, there are strategies that can help us make decisions involving trade-offs. One of my favorite decision making strategies is one made famous by Jeff Bezos: The Type 1 and Type 2 strategy .

Let’s apply this strategy to one of the previous examples.

Do you need to make an algorithm highly performant? Then you may need to make some extreme sacrifices in maintainability and readability.

Let’s assume the development team has determined the following about changing this algorithm:

  • The algorithm is slowing down processing significantly.
  • The amount of time it will take to rewrite the algorithm is trivial.
  • The risk to the business is extremely low if the new version doesn’t work.
  • If the new version doesn’t work, the business process will safely halt execution.
  • The old version can quickly be put back into production if the new version doesn’t work correctly.
  • The business process can be rerun without causing any problems.
  • The new version of the algorithm will be more difficult to maintain.
  • The new version of the algorithm can be easily tested.

Given the above criteria, this is clearly a Type 2 decision, and we can go ahead and make the change.

What happens, though, if we make a change to one of the items in our list?

  • The algorithm is slowing down processing significantly.
  • The amount of time it will take to rewrite the algorithm is significant.
  • The risk to the business is extremely low if the new version doesn’t work.
  • If the new version doesn’t work, the business process will safely halt execution.
  • The old version can be quickly be put back into production if the new version doesn’t work correctly.
  • The business process can be rerun without causing any problems.
  • The new version of the algorithm will be more difficult to maintain.
  • The new version of the algorithm can be easily tested.

In our new hypothetical example, the team has determined that it will take a significant amount of time to rewrite the algorithm. This might make the decision a little harder, or it might not. Does the team have the available bandwidth to attempt a rewrite the algorithm? Would the performance gain make a significant improvement for the business? If the answer to one or both of those questions is “Yes”, then it’s probably still a Type 2 decision.

Let’s change one more item in our list of things we know about the rewrite.

  • The algorithm is slowing down processing significantly.
  • The amount of time it will take to rewrite the algorithm is significant.
  • The risk to the business is extremely high if the new version doesn’t work.
  • If the new version doesn’t work, the business process will safely halt execution.
  • The old version can be quickly be put back into production if the new version doesn’t work correctly.
  • The new version of the algorithm will be more difficult to maintain.
  • The new version of the algorithm can be easily tested.

With this change in criteria, we’re probably now looking at a Type 1 decision. The decision to rewrite the algorithm should be approached deliberately and methodically. Additionally, all stakeholders should be notified and given the opportunity to participate in the decision making process.