Tradeoffs
Why do Tradeoffs Matter?
Tradeoffs matter for a variety of reasons:
- Better Decisions: Who can you make sure you are making the best-informed decision if your analysis might be missing or even completely wrong.
- Understand What You Are Losing: Unfortunately, we can't eat the cake and have the cake in all scenarios. Sometimes we need to accept that we are losing aspects in the sense of others, thats the nature of tradeoffs. For instance, by increasing flexibility will be losing performance, and that needs to be a conscious choice.
- Improve Comunication: When people have the same facts, some decisions are easier. People might disagree with decisions, but when you should your tradeoff analysis will be much easier to get people on board and reduce tensions.
- Feedback: By doing and sharing your tradeoffs analyses you can get feedback from others who might have different points of view and provide valuable feedback.
- Learning: Discussing tradeoffs with workmates is one of the best ways to effectively learn something and at the same time improve your tradeoffs game.
Engineers fail to run tradeoffs analysis, for a variety of reasons. Temptations are real, engineers rush into decisions, therefore doing the wrong tradeoff analysis.
Resist the Temptation
Temptations are forces that will influence you to run the wrong tradeoffs. Understanding such factors and social phenomena makes it easier for you to push back and then run proper tradeoffs. Here are some temptations:
- Feature Factory, Pressure to Deliver: Unrealistic, Shallow, and unseasoned business partners could push for unrealistic deadlines, in what the industry calls: Feature Factory. Feature Factories have no time for tradeoff analysis.
- Get it Done Quickly: Engineers want to get things done, but when you don't understand what you are doing, rushing will only destroy the quality.
- You think you know: Oftentimes people think they know everything about all subjects, are always good to handle, perform research, read books, attend conferences, and always have a student mind that is open to learning at all times. Go spend the time to do some deep work.
Temptations are risks, they may or may not happen. Even so, it is important to be aware of them.
My Tradeoffs Pyramid
I crafted my own tradeoffs pyramid. Diego Pacheco tradeoff pyramid looks like this:
My Tradeoffs Pyramid
Benefits or Drawbacks: Benefits or drawbacks are the targets, the goals of tradeoffs. Typical examples include mantainance, scalability, cost, anti-fragility, isolation, performance, flexibility, time to market, simplicity, and many others. Drawbacks could be the opposite of the examples I just gave. Although it is the TOP of the pyramid, you should not try to aim for them directly, as there is a good chance you will get it wrong. Benefits or drawbacks are the results that happen when we properly apply this pyramid.
Now let's go from the bottom to the top of the pyramid.
Simulations and Understanding: Consider, we want to do tradeoffs on code structure and organization. Let's say we dont understand much about such a matter. The first thing we need to do is seek understanding and look for definitions and concepts like:
- What is it: One example would be: What is a package?
- Similar Concepts: Are modules and packages at the same time?
- Look for other implementations: Do all programming languages threat modules and packages the same way?
- Comparisons: How different form of organization looks like, i.e: By Features, By Layers, By Domain.
Once we have that understanding we need to visualize what's going on. You need to produce a model to reason about. If we were to build a building one of the first things to do is to build a model, like this:
Architecture Model. Source: https://www.masterclass.com/articles/how-to-make-an-architectural-model
Models can be visual, you can use UML. However, models can be done in a bunch of different ways like using a Excel sheet or even a plaintext document. Having a model is important to create simulations. For instance let's consider we want to visualize how the code would look like if we organize by features, layers, or domains. We can create a simple feature and create the classes and packages to see what how looks like, By doing such modeling we can see benefits and issues almost immediately.
Implementation Details: While implementation details sound simple, they are tricky, such an element on my pyramid is something you need to keep in mind. Implementation details will always exist, they are not tradeoffs, people confuse implementation details with drawbacks very often. What you need to keep in mind is: Does the "target" of your tradeoff analysis, let's say code organization really creates the drawbacks or is it a risk? If the risk has a 100% chance of happening, then yes, you found a drawback, if it depends on lots of factors, you need to list these factors or even ignore the drawbacks because it is easy for people to confuse risks with drawbacks. Be careful to not confuse implementation details with natural drawbacks.
Traits: Traits are not drawnbacks, neither pros. Traits are just characteristics of the thing. For instance, we can see a football ball is rounded, that is not a problem or a benefit, it is a fact. Not all facts have benefits or drawbacks. Traits are close to benefits and drawbacks, it means you are close but not quite there yet. Be careful to not confuse traits with benefits/drawbacks.
What: What is the definition of the thing you are doing tradeoffs. You need to be very careful to not confuse your benefits with the thing itself. For instance, I can say that Java is a programming language, but I cannnot say a benefit of Java is a programming language, again is a fact, not a benefit. Now if we say Java is a reliable programming language, that is a benefit and is also a fact, whether you like it or not.
Why: Why is the explanation of something. Why could this be how some phenomena happen. Again do not confuse why and how with the benefits or drawbacks. For instance, if I say Java is compiled and has strong typing. Compilation is not the benefit, the benefit is type safety or correctness, Java compiling code and having types is the explanation, it is the why/how not the benefit or drawback itself.
Benefits / Drawbacks: Finally we get to benefits and drawbacks. The top of the Pyramid is the result of all previous layers of the pyramid, you can't get here without getting the previous layers right. Again, resist writing whatever is on the paper. Make sure you understand the target of our tradeoff analysis, consider all previous points, and make it here.
From the left side of the Pyramid, I have a spectrum with Root Cause and Cause, from the base of the pyramid to the top. Spectrum means the tradeoffs (benefits/drawbacks) are like root causes and weaker concepts like traits, what, implementation details, are causes. You do not want causes, you want the root causes. For instance, the drawback is not a running noise, the drawback is the flu. Running nose is just a cause or symptom of the flu. Flu itself is the root cause of the Flu, Flu's root cause will be contagion from a virus of type A, B, or C for instance.
Tradeoffs are not obvious. Run simulation exercises using the Pyramid and practice a lot and you will see your tradeoff game get sharper and sharper. Tradeoff game does not improve from day to night, and require practice and people that have experience running tradeoffs.
Cheers,
Diego Pacheco
