Pourquoi la Tech tient plus de la pop culture que de l'ingénierie?

En tant qu’actrices et acteurs de la Tech, nous nous pensons souvent comme des ingénieurs et ingénieures : rationnels, méthodiques, cherchant à améliorer nos produits et nos pratiques par l’intelligence collective. Nous parlons d’expérimentation, d’itération, de rigueur… bref, d’ingénierie. Pourtant, quand on observe nos échanges sur les réseaux sociaux ou dans nos réunions, on découvre un tout autre monde. D’un côté, un influenceur proclame que “tester est une perte de temps”. De l’autre, une experte affirme que le TDD est la clé de la robustesse logicielle. Un Scrum Master défend la vélocité en story points pendant qu’une développeuse revendique le noEstimates. Et au centre, les commentateurs tranchent : “tout le monde a raison, du moment que ça vous apporte de la valeur”. Et si, au fond, notre univers technique ressemblait plus à une pop culture qu’à une science appliquée ? Et si, derrière nos débats passionnés, se cachait une croyance partagée : celle que nos opinions valent des vérités ? Dans cette conférence, nous verrons comment nos comportements, nos biais et nos figures d’autorité ont transformé la Tech en un espace de croyances, parfois éloigné de sa nature d’ingénierie. Nous explorerons comment retrouver une posture plus critique et plus rigoureuse : - distinguer opinion, intuition et preuve scientifique - reconnaître nos défauts de posture en tant qu'observateu

Model Tension Heuristics: Preventing Accidental Design Debt

”All models are wrong, but some are useful.” This insight from George Box has become a cornerstone of software modeling. While exploration and experimentation are essential for shaping models, it is often challenging to know when a model is wrong or, worse, when an existing model has become obsolete and is no longer as useful. As a result, unsuitable models may be still used for a long time, leading to different issues not always identified as forms of design debt. These include the spork effect (intrinsic coupling), model fragmentation (extrinsic coupling), and model sclerosis, which ultimately contribute to entropy or the "Big Ball of Mud" phenomenon. These problems arise from undetected and unresolved model tensions. In this talk, we will explore what model tensions are, the complications they cause and why they occur. We will also present a set of heuristics to identify and address different kind of model tensions.

Live Coding The Hive: building a microservices-ready modular monolith

After a decade, the industry has realized that poorly designed microservices can easily turn into a distributed monolith, often more problematic than the spaghetti monolith they aimed to address. To tackle this issue, the concept of a modular monolith is emerging as an alternative approach. However, the challenge still lies in effectively splitting it without falling into the pitfall of tightly coupled modules. The Hive pattern helps you build a microservices-ready modular monolith, by leveraging multiple hexagonal architectures and vertical slicing, each module is loosely coupled and ready to be extracted as a separate service. During this live coding session, we will begin with a legacy spaghetti monolith and migrate it step-by-step to a Hived modular monolith, wrapping up with a demonstration of extracting a module and transforming it into a separate micro-service.

Hexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable

There always comes a point where software becomes so complex and old that it becomes unmaintainable. Updating the technical stack without breaking everything becomes impossible, implementing new features takes longer, and the technical debt is so overwhelming that refactoring becomes exorbitant. What if we told you that all of this is more of a practice problem than a software aging problem? Come and discover through hands-on experience in this 100% live coding session how Hexagonal Architecture can tackle software complexity, making it possible for you to be adaptable and sustainable while helping you manage your technical debt more effectively.

The Hive: a scaling and supple architecture style for your growing and complex domain

In a landscape of scaling domain complexity and evolving responsibilities, organizations often grapple with the question of whether to adopt microservices. The ubiquity of Big Ball of Mud (BBOM) monoliths has reshaped the conversation, challenging conventional notions of system design. However, the deployment strategy for bounded contexts remains elusive. How to split it right by avoiding the pitfalls of a distributed big ball of mud ? How to ensure the cohesion and consistency of our bounded-contexts ? How to reduce coupling between them ? How to deal with the growing complexity of your system ? How to survive beyond our modeling debt and take control back ? Discover the Hive architecture style, a tactical approach that enables you to cope your strategic challenges and align your software business core with your context map. This pattern decouples your deployment strategy from your strategic design, adhering to the principle of “Model once, Deploy as you wish”. By rationalizing the relationship between bounded-contexts and services, the Hive pattern will bring you a supple and scalable design that stands resilient in the face of evolving challenges for brown or greenfield products.

Model Mitosis : ne plus se tromper entre les microservices et le monolithe

Tout comme le développement doit être itératif, le design du logiciel doit changer lorsque le contexte et notre compréhension du problème évoluent. Au fur et à mesure qu'un logiciel se développe pour résoudre plus de problèmes, il devient moins souple dans sa capacité à évoluer. Des tensions apparaissent au sein du modèle métier du logiciel qui peine à rester cohérent. Finalement, il atteint une masse critique et devient un monolithe de code en spaghetti... Comment pouvons nous déterminer quand il est temps de modulariser notre logiciel ? Comment prendre la décision de le scinder en plusieurs modules ou services ? Comment gérer la différenciation progressive de nos modèles métiers tout en évitant les couplages inutiles ? Il n'est pas facile de découper son logiciel en deux car déterminer les bonnes frontières peut s'avérer être compliqué. Découvrez avec nous le Model Mitosis, une approche dynamique utilisée pour diviser un modèle métier en plusieurs modèles qui seront façonnés et découplés de manière itérative. Gagnez en flexibilité afin de mieux déterminer quand diviser votre logiciel en plusieurs services tout en évitant de payer les coût d'échelle des microservices ou bien de devenir un monolithe distribué.

[2h]Architecturoplastie hexagonale d’un backend Node.js : Opération à code ouvert

Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture. Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée. Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ? Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.

Model Mitosis: a dynamic pattern to deal with model tensions

Just as models should be iterative, strategic design should change when the context and our understanding of the problem evolve. As a model grows to solve more problems, it becomes less supple in its ability to evolve. Tensions arise within the model that struggles to stay coherent. Eventually it reaches a critical mass and becomes a big ball of mud. How do we know when it’s time to let new models emerge? How do we carry on the decision to split a model? How can we handle the progressive differentiation of our models while avoiding unnecessary coupling? It’s not as easy as a clean axe cut in the middle, finding the right boundaries is hard. We would like to introduce the Model Mitosis, a dynamic pattern used to split a model into multiple ones that will get shaped and decoupled iteratively.

Conway's Law: When Best Practices Are Not Enough

Your users are still struggling to retrieve the information they need, despite you have done everything to model your domain and ease the user experience? Although you follow best practices, did you ever noticed that the software often deviates from the product design, the technical vision and sometimes the software quality is even below expectations? What if we told you that all of this is linked ? There is a force that has an important influence on your product, your user experience, the quality of your software and your architecture ! During this talk, come and discover the Conway's Law that has a magical power over what you build, whatever your job profile is. We will see the impacts of this law on the different aspects of the software based on scientific studies and feedbacks from the field collected over the years.

Y'en a marre du Software Craftsmanship!

OAUTH 2.1 explained simply (even if you are not a developer) !

It is very difficult today to deploy an application on the web without dealing with OAuth2. Designed to better protect users, this authorization delegation protocol has become a standard in the industry. However, haven't you cried trying to understand the concepts of OAuth2? Let's be honest, this is quite easy to get lost between the different roles and the multitude of flows of this protocol. And its complexity has discouraged more than one! However we can't deliver without it, so we try to setup some OAuth flow and usually... this is really painful. But don't worry, whether you have a tech profile or not, this talk will help you to finally understand the intricacies of OAuth simply, including the new version 2.1, using analogies from everyday life!

Train Booking Context Map

Loi de Conway : Lorsque votre conception produit se fâche avec votre organisation

Des utilisateurs qui ont toujours du mal à récupérer les informations dont ils ont besoin, alors que vous avez mis le paquet sur l'expérience utilisateur ? La frustration de voir qu'une fonctionnalité implémentée est rarement la solution fonctionnelle idéale que vous aviez défini, car il y a toujours un "mais" ? Ou plus techniquement, avez-vous des APIs découpées d'une manière qui semble au final arbitraire et qui ne suit pas le métier ? La sensation que votre organisation est orthogonale à vos objectifs ? N'avez-vous jamais remarqué, que bien que vous soyez agile et vous suivez les bonnes pratiques, le logiciel qu'on construit s'écarte souvent de la vision produit, technique et parfois même des besoins de l'utilisateur que l'on a pourtant passé du temps à récolter ? Et si on vous disait que tout cela est lié, et qu'il existe une force qui a une influence certaine sur votre produit, votre expérience utilisateur et votre architecture ? Lors de ce talk venez découvrir la Loi de Conway, cette force méconnue qui a un pouvoir magique sur ce que vous construisez quel que soit votre métier. Nous verrons ses impacts sur les différents aspects du logiciel et nous apprendrons comment l'apprivoiser.

[LBC] Osez Devenir Speaker !

Devenir Speaker, c’est peut-être quelque chose qui vous fait envie. Mais qu’est ce qui vous empêche d’aller plus loin ? Sûrement cette petite voix qui vous dit qu’il y a beaucoup de gens plus qualifiés que vous pour parler d’un sujet. Qu’est ce que vous avez à partager de toute manière ? Et puis parler devant une centaine de personnes ce n’est pas pour vous, les gens qui arrivent à faire ça ont certaines prédispositions… Lors de cette session, nous verrons ensemble que cette petite voix a tort. Vous pouvez le faire ! Et pour bien se lancer, nous verrons les bonnes pratiques de la création d'un talk jusqu'à la réalisation de celui-ci: le choix du sujet, la création du talk et la candidature aux conférences.

REST next level : Crafting Domain-Driven Designed web APIs

You have just coded your business logic by applying the principles of Domain-Driven Design! But when comes the time to write your API, you are facing a serious issue! All the intention and the expression of your domain go up in smoke to fit the blankness methods GET, POST, etc. Denatured by the REST layer, the business workflow is then deported on the consumer side to compensate for the limited vocabulary of this well-known CRUD protocol... During this talk, we will see how to bring the business intent back inside the REST API by finally being able to expose our domain services and agregates' methods. The business workflow will also be encapsulated in the REST API in order to have the power to guide our consumers through the workflow of our domain.

Architecturoplastie hexagonale d’un backend Node.js : Opération à code ouvert

Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture. Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée. Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ? Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.

Bien répondre aux besoins utilisateur, c'est surtout une histoire de comportement (logiciel) !

OAuth2.1 expliqué simplement (même si tu n'es pas dev) !

Architecture Hexagonale : un pattern de gestion de la complexité logicielle et de la dette technique

Il arrive toujours un moment où, le logiciel est tellement gros et vieux qu’il devient inmaintenable. Impossible de mettre à jour la stack technique sans tout casser, les nouvelles fonctionnalités deviennent de plus en plus longue à implémenter et la dette technique étant tellement lourde que le refactoring devient exorbitant. Et si on vous disait que tout ça était plus un problème de pratique qu’un problème de vieillesse du logiciel ? Venez découvrir par ce retour d’expérience, comment l’Architecture Hexagonale peut tacler la complexité logicielle en vous permettant d’être évolutif et pérenne tout en vous aidant à mieux gérer votre dette technique.

CONF - Osez Devenir Speaker !

Devenir Speaker, c’est peut-être quelque chose qui vous fait envie. Mais qu’est ce qui vous empêche d’aller plus loin ? Sûrement cette petite voix qui vous dit qu’il y a beaucoup de gens plus qualifiés que vous pour parler d’un sujet. Qu’est ce que vous avez à partager de toute manière ? Et puis parler devant une centaine de personnes ce n’est pas pour vous, les gens qui arrivent à faire ça ont certaines prédispositions… Lors de cette session, nous verrons ensemble que cette petite voix a tort. Vous pouvez le faire ! Et pour bien se lancer, nous verrons les bonnes pratiques de la création d'un talk jusqu'à la réalisation de celui-ci: le choix du sujet, la création du talk et la candidature aux conférences.