Picking a stack, a language, a cloud provider, a database or an architectural approach is a bet. Not in the gambling sense, but in the “picking the probable future” sense. Acknowledge that and act accordingly.

Where The Puck ¹

You decide on technology for a reason. If your team is larger, you may be forced to conjure an explanation, seriously called “analysis”. And if the stars are right, it is related to your business and teams.

The selection should be driven by three things:

1. Particular circumstances of your business, technology, team, and where you stand on which scale
2. The current state of the technology and market
3. Your best guesstimate on where both are going

It is the last point that is most important, yet I rarely see it captured. Even if I see them in Architecture Decision Records, they are treated as assumptions.

The difference between an assumption and a bet is that you expect upfront for the latter to be wrong.

Probabilistic Thinking

Making a difference between assumptions and bets has consequences for the design. Assumptions are healthy since they lead to simplifications. Correctly selected bets lead to easier adaptation for future changes.

Capturing both assumptions and bets provides important guidance for the future. It tells you (and more importantly, your successors) when to start revisiting past decisions. It helps to manage your path dependence. If you are up for it, assigning confidence to the bets is a good thinking exercise.

On the other hand, the amount of time spent on capturing both bets and assumptions should be proportional to their impact. But not capturing a bet is a bet on its own: you have just decided to make a bet unconsciously.

The important part is betting verification, which is where the list makes your life easier. Depending on what you do, upfront design, prototype or milestones during development are all valid choices.

Going With The Crowd

Engineers who follow blogpost-driven development or technology choice are frowned upon. I think it's for the wrong reason: in a lot of circumstances, following a fashion in technology is a perfectly rational choice.

I think a lot of pushback stems from a famous Graham essay about how his webshop startup won because of Lisp. There is merit to it: if you are the top 1%, feel free to select obscure technologies, partner with the other 1%, and beat everyone.

But for the 99% of us, we don't build our software from scratch—and we also don't live in 1995 anymore. We build on top of a vast selection of libraries and frameworks built by others. Making sure those dependencies are moving in the same direction as we do is critically important.

Because of the winner-takes-all property that rules most of the technological wars, following the crowd makes perfect sense. If you go with enough people, the sole act of doing so changes the technological landscape itself, altering the number of available technologies. This can turn a bad choice (as in suboptimal for your use case) into a good one since the sheer amount of people having the same problem warrants either a change to the selected technology or a sufficient workaround.

When this goes very wrong is when people in the crowd are too different from you. If you don't work in a large tech corporation and you are selecting the same technologies as FANGAM, I beg you to double-check. If you are using them because they use them as well, I’d argue you should change your selection process².

Choosing Your Skills

The same selection process applies to the selection of skills you want to learn. This is especially important if you are coming into the field: by definition, you don't have enough knowledge to make an informed selection. Whether you choose C, Java, or Python as your first programming language, it puts you on a trajectory that takes conscious effort to change. It is useful to know why you picked one and when is the time to correct it.

Conclusion

Technology decisions incorporate your guess about the future—and your bet on how they will turn out. Being aware of it and making this guess explicit helps “future you” a lot. First, you will know when it goes wrong and get a prompt to change the course. Second, it should help you get better at anticipating future uncertainty and not to fall victim to storytelling bias.

---

1. I know, I know ↩︎

2. I've done that in the past as well. I was under a naïve impression that it increases the probability of backward compatibility and ongoing maintenance. Let's say that I was more vulnerable to marketing back then and that I wrongly perceived a corporation as a coordinated entity. ↩︎