Few months ago, I’ve read this article: How We Built a Self-Healing System to Survive a Terrifying Concurrency Bug At Netflix.

What I loved is how unconventional the solution was. However, unconventional doesn’t mean irrelevant, their solution kept the software running during the weekend, and this without any human intervention. The solution wasn’t perfect, but it was “good enough” and even more, respectful of people’s time.

By the end, it concludes with a concept that somehow inspired me: “technological adulthood”.

Recently, Antoine Caron published a blog post about his AI usage. Thanks to him, I’ve discovered the /ai ‘manifesto’ and I want to do the same here. Maybe you’ve reached this post by typing /ai in the URL.

My posts

All the posts in this blog are written by myself, I don’t use any generative AI to produce content.

Creating a blog post is an interesting activity, it requires me to challenge and organize my thoughts before trying to write on a topic. Today, I use this blog as a place to put thoughts that I think are worth writing about and sharing.

In early 2020, I’ve read the book Programming Elixir 1.6. At that time I had one goal: to have an introduction to the actor model with a language that supports it by design, in this case Elixir. I think it was a good read and I achieved my goal, even though I didn’t feel able to design a complete system using this pattern.

However, I realized I’m using some actor model concepts for a few years now. In my previous post, I’ve mentioned types of effects produced in a CQRS/ES system, one of them is triggering new processes.

If you’ve already developed a software using the event sourcing pattern, you’ve probably faced difficulty: How-to design good events? What is a good event granularity?

Indeed it’s difficult to produce good events that will not harm our design. As a seasoned developer with event sourcing, I’m still struggling with this, even if I’ve developed several heuristics over time.

In this blog post, I will share with you these heuristics. But keep in mind this is not some kind of best practices. Best practices are useful for contexts where we can apply a method without any (major) form of adaptation, there’s nothing that simple when developing a custom software for business. The following heuristics are rather a way to ask ourselves good questions and drive our thinking.

Nowadays, most of the services we’re using are online and available 24/7. If, like me, you’re working on a company that provide this kind of service, you’re probably aiming for such availability. As I’ve already highlighted it, it has a huge influence on how you should code and deploy your software. Indeed, to maximize availability, you’re probably aiming for a zero downtime deployment.

Zero downtime deployment includes several topics. Today I want to focus on how to achieve a database migration without service interruption.

I’ve recently gave a talk with my friend Aurélien about the heuristics we’ve developed after using CQRS/ES for several years.

After our talk, we had a chat with some developers. We concluded that choosing a state-based oriented approach (like CRUD) seems to be the default solution, such choice seems to remain unchallenged. On the opposite side, choosing an event-based systems (event sourced or event driven) will very often be heavily challenged.

Thinking in events

In a previous post, I’ve expressed some kind of thought experiment to highlight how natural events can be:

I had the chance to work few months in Agicap, an enterprise producing a cashflow management SAAS for businesses.
It was a great mission, my team worked a way that I consider to be, so far, the most efficient and pleasant in my career. We managed to produce value at a constant speed while keeping a full control of our code, not allowing any kind of quality depreciation over time.

This blog post is just a recap of all practices we had in place and why I believe it was beneficial for us. Please, keep in mind we chose these regarding our context, this is not some sort of silver bullets list.

Au cours de ma carrière, j’ai été confronté à plusieurs reprises à des clients et/ou des acteurs internes qui souhaitent assurer un haut niveau d’uniformisation sur le code des applications. Cela se traduit par des conventions de style, de nommage, et parfois même des choix plus impactant comme des frameworks ou des architectures spécifiques. Dans les cas extrêmes, les propos de ces personnes laissaient entendre le refus d’un quelconque écart avec ces règles.

Un biais cognitif et un usage erroné

Les développeurs aiment bien les acronymes pour énoncer des “bonnes pratiques” (KISS, DRY, SOLID, etc…). Souvent, l’idée véhiculée par ceux-ci est très simple à appréhender.
Cependant, nous souffrons d’un biais cognitif énorme : plus une information est simple à intégrer, moins elle est remise en question / challengée. Et celle-ci est encore mieux intégrée si elle ne va pas en contradiction avec vos croyances.

Voilà maintenant plus de 5 ans que j’applique une approche TDD (test-driven development) sur l’ensemble des projets sur lesquels j’interviens. Si j’utilise toujours cette méthode, c’est parce que la présence de tests me donne confiance dans le code que j’écris :

• Je m’assure qu’il fait bien ce que je souhaite.
• J’améliore constamment son design par du refactoring.
• Les tests mettent en lumière la très grande majorité des régressions que je peux introduire lors d’un refactoring ou d’une évolution.
• Je réduis ma charge cognitive et me focalise sur le cas métier que je suis entrain de traiter (les tests s’occupent de vérifier les autres cas pour moi).

Modifier mon code est donc une capacité permise grâce aux tests et que je souhaite conserver tout au long d’un projet : je peux améliorer son design pour le garder constamment adapté aux problèmes métier que je veux résoudre.