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
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.
Par : Bastien David – Le 9 juin 2026 à Grenoble
L’architecture logicielle n’est pas seulement une affaire de schémas : elle est aussi le reflet des organisations qui la produisent. Bastien David explore l’impact des structures d’équipe sur les décisions techniques, les limites des comités d’architecture, et les formes de décentralisation qui permettent davantage d’autonomie. Un talk pour réfléchir à la manière dont on peut influencer, à son niveau, une culture d’équipe plus collaborative.
Christopher Alexander’s keynote speech at the ACM Convention on “Object Oriented Programs, Systems, Languages and Applications”, (OOPSLA) in San Jose, CA, October 6 - 10 1996. Christopher Alexander connects his architectural work on patterns and pattern languages [03:40] with the field of computing. He introduces the theoretical framework behind his upcoming work, "The Nature of Order" [04:12], and expresses concern about the lack of "living structure" in the modern built environment [05:52]. Alexander emphasizes the moral component underlying his work, questioning if computing patterns also strive to improve human life [13:39]. He discusses the importance of a pattern language's ability to generate coherent wholes [17:32], the recursive structural characteristics related to patterns [21:11], finding objective criteria for "life" in structures [24:57], and the concept of "unfolding wholeness" [41:25]. He concludes by urging the computing community to consider their potential role in creating living structures in the world [59:22].
Transcript : https://www.patternlanguage.com/archive/ieee.html
Learn to write better, resilient CSS
If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves.
Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.
In this video I analyze the DOOM project by id Software.
Comment, like, subscribe, let’s trigger the algo!
The focus will be on software architecture, technical limitations, technical concepts.
If you like the content comment, like and subscribe to support the channel!
- 00:00 DOOM
- 03:18 Software Architecture
- 08:06 Build Process
- 10:04 Component Diagram
- 11:07 WAD Files
- 13:20 Main Loop
- 14:35 2D Renderer
- 20:45 3D Renderer Intro
- 24:22 Binary Space Partitioning
- 27:45 BSP Example
- 31:03 Player FOV
- 35:22 Wall Clipping
- 40:30 Visplanes
- 41:25 "Masked"
- 42:21 Conclusion and Lessons