I'm passionate about programming, I simply love it.
I like to learn and this industry
brings to me the opportunity to discover new amazing stuff almost every single day.
Constant learner on how to improve writing clean and reliable code.
Mutability × Time: The Compound Risk series.
Proven techniques for containing the compound risk of mutable state over time. From theoretical patterns to a successful real-world refactoring that eliminated invisible coupling.
Mutability × Time: The Compound Risk series.
Why components become secretly coupled through shared mutable state. Examines how invisible dependencies erode trust and create debugging nightmares separated by both code and time.
Mutability × Time: The Compound Risk series.
The anatomy of object decay over time. Examines how instances progress through Birth, Initialization, Drift, Contamination, and Corruption—and why each stage compounds the previous problems.
Mutability × Time: The Compound Risk series.
Why longer-lived mutable instances become exponentially more dangerous over time. Explores the counterintuitive relationship between object longevity and system reliability through a real-world state management failure.
I read A Philosophy of Software Design about 18 months back. It's a well-structured, concise read about managing complexity in software design. I don't think the suggested approaches are applicable in all situations (and John Ousterhout says this himself IIRC), but I recognised a lot of the problems described in the book and found it provided some useful ways to articulate concepts during code reviews (eg. whether adding a shallow function is increasing complexity in a codebase, if complexity can be pulled down into an implementation, or where it's useful to have consistency in the code).
"The definition of insanity is doing the same thing over and over again” - this quote attributed to Einstein warns us of the danger of magical thinking, hoping that trying something just one more time will achieve success when before we failed. But is this really insanity? In this talk, I’ll argue that retrying things actually does make a lot of sense, and is in fact key to improving the resilience of a distributed system. Along the way, I’ll explain the importance of timeouts, retry limits and knowing when giving up does make sense. I’ll also show how retries can be made safe (and help avoid draining your bank account), and perhaps we’ll get to examine that Einstein quote in a bit more detail…
We all want the best design but often that is not directly obtainable. Our tools for understanding systems behaviour may lead us to the abstractions we would want to use in a rewrite but what about the abstractions that exist in the system now? Do they matter? What about the structure? Are there unnamed concepts we can see through the current cohesion and coupling in the system that will help us get to where we need to go? In this talk, Michael Feathers will describe cases where being aware of what currently exists leads to better solutions. We can often leverage what we have instead of building up a domain from a greenfield.
Welcome to The Pragmatic Engineer! Today, I’m thrilled to be joined by Grady Booch, a true legend in software development. Grady is the Chief Scientist for Software Engineering at IBM, where he leads groundbreaking research in embodied cognition. He’s the mind behind several object-oriented design concepts, a co-author of the Unified Modeling Language, and a founding member of the Agile Alliance and the Hillside Group. Grady has authored six books, hundreds of articles, and holds prestigious titles as an IBM, ACM, and IEEE Fellow, as well as a recipient of the Lovelace Medal (an award for those with outstanding contributions to the advancement of computing). In this episode, we discuss: • What it means to be an IBM Fellow • The evolution of the field of software development • How UML was created, what its goals were, and why Grady disagrees with the direction of later versions of UML • Pivotal moments in software development history • How the software architect role changed over the last 50 years • Why Grady declined to be the Chief Architect of Microsoft – saying no to Bill Gates! • Grady’s take on large language models (LLMs) • Advice to less experienced software engineers • … and much more!
In short, Conway's Law says any organisation that designs a system will come up with a system design that copies the organisational communication structures. Over the years, many individuals rephrased Conway's Law in various ways. Every paraphrase brings new insights and non-negligible consequences. Sometimes they give the impression of contradicting each other. However, in the end, they all come to the same conclusion. The organisation and the system keep each other in balance. Modifying the organisation will have an impact on the system. Modifying the system will have an impact on the organisation. Not considering that will cause friction in the organisation or the system with dramatic consequences. To be competitive as an organisation in the market, and to effectively design the right thing our customers expect us to deliver, we'd better understand and take advantage of this. About Thierry de Pauw: Thierry is a lean IT Engineer at the fintech startup Abbove. On the side, he founded ThinkingLabs, an advisory firm for optimising IT delivery while reducing stress, burnout and fatigue. From time to time he is asked to conduct technology due diligence for investors to review the technology capabilities of organisations. Thierry is a CI/CD advocate and jack-of-all-trades. Instead of balancing quality & delivery, he believes and practices that better quality is actually a way to more and better deliveries.