If we get very philosophical, every decision is a tradeoff leaving behind an infinite number of different decisions that could’ve been made instead. But then this post wouldn’t make sense, so let’s better not.
Whenever we’re faced with a limited number of choices, taking a decision is a balancing act between a high number of variables. On one side are the options, which should have objective pros and cons and on the other side, there’s a set list of criteria, each with different levels of importance for this particular decision. That would give each choice a value based on which of the criteria it fulfils.
Our daily lives are filled with easy decisions, but they’re only easy because our brain is trained to take them. It has a perfect model in which to calculate each possible choice’s value and just gives us the result. And, if we extrapolate that idea to Software Development, making decisions about our architecture, design or dependency choices and so on would be trivial.
R
I
G
H
T
?
Not so Trivial
Unfortunately, we humans are exceptionally bad at consciously copying what our brain does when we’re not paying attention, and so there’s really no way we can dig into these expertise to make decisions. Also, we’re really really bad at seeing the future, and most of the decisions our brain makes by itself are grounded on the fact that it knows what’s most likely going to happen. So, what can we do about it?
The Dependency case
Today, we discussed how to decide wether an external dependency is worth adding to a project or not. The tradeoff we make with external dependencies is wether we value the time it would take to do it ourselves higher than the added weight and complexity it brings to the project. But deciding on that tradeoff is particularly hard, and as developers we’ve been constantly trained to avoid reinventing the wheel. That builds an instinct to always reach out to the vast knowledge base of the internet as a first step. But without a clear model on how to evaluate external dependencies, it’s hard to decide which one to use, or wether one should be used at all.
Periklis, who’s twitter account I couldn’t find, talked at length about the criteria his team had used to make one such decision. Some of the criteria, as I remember them, were:
- Performance ➡ How important is time it takes to load the website?
- Feature Difficulty ➡ How long would it (probably) take us to write this ourselves?
- Requirements Flexibility ➡ Can the requirements be compromised by using a dependency that doesn’t fulfil them all?
- Developer Quality of Life ➡ Will this dependency make our lives better, easier and happier?
- … others that I forgot 😭, but you get the idea.
In his case, the requirements weren’t flexible and performance was of high importance. So, of course, when dependencies didn’t fulfil every requirement, it was easy to make the decision to ditch them. But it was only easy because these criteria were mapped to values of importance. And that brings us to the whole conclusion of decision making:
Unsorted Criteria are Worthless.
Decisions cannot be made by ticking all the boxes. They must be made by ticking all the right boxes, even if some remain unticked.
This is something we do every day, for almost everything but we’re not very conscious about it. But what if we were? I am planning to run a little decision making experiment based around these criteria and see how that goes.