Ma réaction à un commentaire (je ne l'ai pas publié).
@SirBenJamin_ 1 hour ago
In my experience, most coupling problems (and other architecture problems) are caused by teams where everyone works on all parts of the codebase, i.e people don't specialise in a particular area, they just pick up the next ticket on the backlog, and then even worse, other people who also have no experience in the area review the code. Managers will see this as a good thing, as they think they're getting more bang for their buck by 'spreading the knowledge.' ... but I really don't think it ever ends up like that, and the codebase suffers
I think "everyone works on all parts of the codebase" could not be a problem per se if the knowledge is evenly distributed. In very big systems it might not be possible and thus I agree with you that specialization could be an useful strategy. Also, you back this with your experience, so empirical evidence strenghtens your point.
In systems not so big, I think that T shape profile along with good ownership distribution (with pair programming, ensemble programming, ADRs), could also have positive effects on coupling problems. Meaning having knowledge a bit larger than hers scope could help having a glance of neigbourg culture (such as how mapping is done in the team next to me).
Techniques such as "swarming" : helping others being stuck or learning things outside of our initial scope (ex. QA, learning a bit of programming skill, Backend learning a bit of frontend ...) might help growing more shared mental models and thus slowly growing in the direction of full stack profile.
This lovely comic illustrates it pretty well I think : https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
Quelques très bons sites et newsletters pour une veille culture numérique technocritique - édition 2025
12 mai 2025
Aujourd'hui plus que jamais, il est indispensable de s'informer, avec exigence, gourmandise et esprit critique (y compris pour penser contre soi-même). Et ce dans tous les domaines. En matière de culture numérique, voici ma sélection personnelle ET actualisée (La dernière édition datait de 2020) de sites, newsletters et podcast permettant de réaliser une veille culture numérique, avec un angle technocritique. Deux précisions importantes. D'abord, cette liste est non exhaustive et sans ordre logique. Ensuite, la plupart (mais pas tous) de ces contenus sont en accès libre, mais pensez à donner à leurs autrices et auteurs, car créer du contenu de qualité représente un énorme investissement en temps !
Podcast
by Felienne Hermans & Hanna Schraffenberger
The Computer Science Off Course podcast brings you one paper or book each week to widen your view on what Computer Science is, and what it could be.
Turing, Naur, Dreyfus, Laurel, and many more will bring some much-needed change in perspective for people who grew up on an information diet of only complex algorithms, programming, and math!
Read along with Felienne and Hanna, do the homework and see that there is more between heaven and earth than computers and compilers.
The past 3 years of work in NLP have been characterized by the development and deployment of ever larger language models, especially for English. BERT, its variants, GPT-2/3, and others, most recently Switch-C, have pushed the boundaries of the possible both through architectural innovations and through sheer size. Using these pretrained models and the methodology of fine-tuning them for specific tasks, researchers have extended the state of the art on a wide array of tasks as measured by leaderboards on specific benchmarks for English. In this paper, we take a step back and ask: How big is too big? What are the possible risks associated with this technology and what paths are available for mitigating those risks? We provide recommendations including weighing the environmental and financial costs first, investing resources into curating and carefully documenting datasets rather than ingesting everything on the web, carrying out pre-development exercises evaluating how the planned approach fits into research and development goals and supports stakeholder values, and encouraging research directions beyond ever larger language models.
If you like this Kata, check out another Kata I’ve published using the example of an online car dealership: https://medium.com/nick-tune-tech-strategy-blog/architecture-ddd-kata-online-car-dealership-540c534121e2
If you would like to learn or practice how to break up a large business into domains and use them as the foundation for your software architecture and team organization, I have created a strategic domain-driven design kata that you may find useful. It’s based on the industry of online takeaway ordering and delivery using a fictitious business called Delivericious.
You can find the Miro board here: https://miro.com/app/board/o9J_l45tkpU=/
Stratégie d'accessibilité un sujet que vous ne pourrez pas rattraper sans anticipation, la gestion hiérarchique des expertises. Traduction fiche du gouvernement anglais (#UK).
Dans le schéma pluriannuel d'accessibilité numérique, il y a une partie concernant la constitution des équipes (formations, promotions, embauches...). C'est une obligation légale d'annoncer la politique qui va permettre d'améliorer l'accessibilité.
Souvent, c'est : on a 2 personnes, on prévoit un stagiaire et un #UX ou un #Dev aura une petite formation. Pour un petit organisme, ça marche, mais pour un grand organisme, c'est bien plus complexe.
Si on pose les choses, on se rend compte qu'il faut faire des enquêtes estimer les compétences dans tous l'organisme, embaucher des experts, des auditeurs, former des spécialistes... combien d'#experts, #ambassadeurs pour X employés.
Il faut un référent expérimenté pour faire cela, une personne qui comprend tous les tenants et les aboutissants capable de mettre tout le monde à une place (estimation de l'expertise), prévoir des progressions, prévoir des reconversions, protéger/assister des profils.
Le référent accessibilité numérique va échafauder un plan (qu'il publiera dans le plan d'action) pour gérer les compétences pour le suivi qualité.
Dans le document ci-dessous (publier par GOV.UK), vous pouvez voir un aperçu des types de profils qu'ils ont déterminé et la manière dont ils les ont décrit.
Dans un grand #organisme ça pourrait constituer un plein temps. Alors que souvent il n'y a pas de référent, ou un seul référent peu expérimenté sur ce sujet.
Au delà des déclarations et schéma pluriannuel manquants ; vous pouvez donc essayer de comprendre le retard pris en France sur le sujet, c'est #abyssal.
(Sachant que ce n'est une fois ce plan stabilisé que vous pouvez intégrer concrètement la prise en compte de l'accessibilité dans un système #IA))
Car pour monter cela c'est d'abord du temps, mais aussi des #experts en interne. Et à force de ne pas prendre en compte l'accessibilité en France, des experts ++ en France, on en a presque pas.
Quand la DGCCRF - Ministère de l'Économie ou l'@arcom nous disent faire des contrôles, et progresser... c'est vrai je rigole. Les organismes français écopent le bateau à la petite cuillère.
#WCAG #RGAA #A11Y #Compliance #RH
Simon Bonaventure Frederic Halna A11y France
Key Takeaways
- Pull Request-based async code reviews are a prevailing way of reviewing code in our industry
- When feedback is invited only after making a lot of changes, it becomes very difficult for both the PR reviewer(s) and the author to course-correct and build in quality
- Delays are an inherent property of asynchronous reviews, and they increase PR batch transaction cost
- With small Pull Requests, we lose throughput if we review them asynchronously because delays in communication start dominating PR lead time
- Co-creation patterns, Pair and Mob Programming enable continuous code review which enables both high throughput and high quality
For this online event, we will have the opportunity to receive Dragan Stepanović as a speaker.
After a brief introduction of our community, Dragan will explain the Systems Perspective of the LLM-assisted coding.
Abstract
This will not be your usual "all roses" talk on GenAI nor one that hijacks your amygdala with claims such as "Most developers are going to be replaced by coding agents in 9-12 months!" or "If you don't jump on the train, you're going to be left out!".
For product development teams, organizations, and their customers, every technology they want to adopt, however innovative it is or may seem, doesn't operate in isolation, but as part of a broader system. Ignoring this fact is likely to make things worse instead of achieving the promised huge productivity boost, because any change in a system affects its dynamics in a way that feeds back to affect that change in turn. Some parts of the dynamics accelerate, some start pushing back. It's becoming increasingly important to take a systems perspective on attempts to adopt a technology and understand what desired, but even more importantly, unintended consequences it's likely to cause.
I'll be diving into topics that are likely to stir the pot with uncomfortable, but important questions that a growing number of teams and organizations are facing on this journey. Great, we have this heavy machinery that can produce so much more code in a unit of time, but what do we do with all the piled-up inventory of unreviewed code? What about comprehension debt? How do we keep the ability to reason about the system? Can we replace the process of creating and evolving a product with its output (code)? LLM-assisted vs agentic coding, and which makes sense in which context?
This technology and its adoption are still in their infancy and we're operating in an uncharted territory, so no one really knows yet all the effects that will play out, but looking at it through Systems Thinking, Lean, Theory of Constraints, and XP lenses can provide a useful level of foresight into the distribution of outcomes that might play out.
About Dragan
Dragan is based in Berlin and as a principal engineer helps companies evolve their engineering culture, tame their bottlenecks, and maximize their throughput of the value.
Typically, in search of better ways of working, exploring ends of the spectrum, and helping teams and organizations try out counter-intuitive ideas that initially don't make a lot of sense, but surprisingly end up as completely opposite of that.
He enjoys endless discussions connecting XP, Theory of Constraints, Systems Thinking and Lean.
Retours d'étonnement d'une personne aveugle qui découvre les problèmes d'accessibilité d'un site en quelques minutes. En tentant de naviguer avec les technologies d'assistance.
LLMs have been trained on decades of freely available Java specifications, including JSRs, JEPs, MicroProfile and Jakarta EE. They know the patterns. They know the standards. Now let's put them to work. In this live coding session, we'll use LLM agents to build production-ready Java applications quickly. No slides, no theory - just real code, real prompts, and real results. We'll start with a typical enterprise requirement and demonstrate how to guide LLMs to generate clean, maintainable Java code following BCE/ECB architecture patterns that actually work in production. You will learn how to effectively access the LLM's in-depth knowledge of Java specifications, how to continuously improve the generated code with each iteration, and how to maintain a high velocity without creating a mess. Expect live coding, real-world scenarios from actual projects, and honest discussion about where LLMs excel and where human expertise remains crucial. Bring your questions - we'll solve them with code.
Guidelines for Agentic development.
"Put your AI on rails."
BCE architecture · Java · Web standards
Adam Bien
The Boundary-Control-Entity (BCE/ECB) pattern is a software architecture pattern that organizes code into Business Components. A Business Component is a package or namespace comprising three distinct layers, each with specific responsibilities. Business components adhere to the principles of maximal cohesion and minimal coupling, and are named after their domain responsibilities.
Some of you may know Emacs as the rival to Vim, and we know that Vim has been increasing popularity. However, I like to go against the grain, which means I pivoted to Doom Emacs a couple years back, and I haven't looked back. In this video, I’m diving deep into why Doom Emacs has become my go-to choice for coding and productivity. If you’re tired of your current setup or just curious about what Doom Emacs can offer, you’re in the right place!
Doom Emacs is not just another text editor; it’s a powerful framework that enhances the Emacs experience. With its keyboard-centric workflow, you can do everything from coding to managing tasks, all in one place. I’ll share my favourite packages, explore some underutilized features, and even show you how it integrates seamlessly with my Linux distro, Nix.
One of the standout features for me is org-mode, which has transformed how I manage tasks and notes. I’ll walk you through my simplistic workflow and how you can easily adopt it to boost your productivity. Plus, I’ll discuss the benefits of using open-source software and how Doom Emacs supports a variety of programming languages without the hassle of extensive customization.
If you’ve ever felt overwhelmed by the complexity of Emacs, don’t worry! I’ll explain how Doom Emacs simplifies the experience while still allowing for customization. You’ll learn how to become a power user without spending hours reading documentation. And for those of you who have experience with Vim, you’ll be pleased to know that your skills transfer over seamlessly with Doom Emacs’s evil mode.
Join me as I explore the incredible capabilities of Doom Emacs, from its intuitive key bindings to its stability and performance. Whether you’re a seasoned developer or just starting out, this video will provide valuable insights into how you can enhance your coding experience. Don’t forget to like and subscribe for more content on Emacs and coding productivity!
If you're writing for a living, as I do, I think you should be writing in Obsidian.
This session is about practical, no-nonsense coding. We'll explore lean Java 21+ practices and patterns that eliminate bloat and hacks that increase productivity. We will start with structuring and organizing backend monoliths and microservices, cover testing, then move on to decoupling, abstractions, Data Oriented Programming, automation with pure Java and the impact of LLM assistants on design and code structure.
Your questions and scenarios are not only welcome, they're essential.
Adam Bien