Shades of Conway's Law
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.
Oct 14 2024Visual Agility: Why We Model
Design of complex systems is hard -- wickedly hard! It takes all the cognitive assist we can muster. Trade-offs must be made because there is interaction -- not just interaction among components to create a capability, but interaction among properties. And interaction between the system and its users and containing systems(-of-systems). And more! These systems are evolving -- the more agile, the more we try to take this co-evolution, this learning across boundaries, this symmathesy, into account.
Jul 19 2024The Log: What every software engineer should know about real-time data's unifying abstraction
One of the most useful things I learned in all this was that many of the things we were building had a very simple concept at their heart: the log. Sometimes called write-ahead logs or commit logs or transaction logs, logs have been around almost as long as computers and are at the heart of many distributed data systems and real-time application architectures.
Disributed Systems Event Sourcing Software Engineering
Jun 8 2024A Distributed Systems Reading List
This document contains various resources and quick definition of a lot of background information behind distributed systems. It is not complete, even though it is kinda sorta detailed. I had written it some time in 2019 when coworkers at the time had asked for a list of references, and I put together what I thought was a decent overview of the basics of distributed systems literature and concepts.
Apr 25 2024A Philosophical Look at System Dynamics
Dartmouth College, Hanover, New Hampshire, Spring of 1977. In this lecture, Donella Meadows takes on a more philosophical concept. How can we bring ourselves to be aware of the assumptions we make as systems thinkers? She asserts that models are a set of assumptions. Donella Meadows defines some of these system dynamics assumptions (such as causal relationships and feedback loops) in this video.
Apr 25 2024So you think you want to write a deterministic hypervisor?
What is a deterministic hypervisor and why do we need one anyhow?
Apr 4 2024Designing Fault-Tolerant Software with Control System Transparency
GN&C Fault Protection Fundamentals by Robert Rasmussen, who works for the Jet Propulsion Laboratory, which is an organization that works closely with NASA on designing spacecraft. GN&C is guidance, navigation, and control. These are the main software systems here. This paper actually distills a ton of experience spent with really thinking through how to build really fault tolerant systems into some core principles.
Architecture Disributed Systems Video
Mar 5 2024Design Principles Behind Smalltalk
The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available. We have chosen to concentrate on two principle areas of research: a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware, and a language of interaction (user interface) that matches the human communication system to that of the computer. Our work has followed a two- to four-year cycle that can be seen to parallel the scientific method: Build an application program within the current system (make an observation) Based on that experience, redesign the language (formulate a theory) Build a new system based on the new design (make a prediction that can be tested) The Smalltalk-80 system marks our fifth time through this cycle. In this article, I present some of the general principles we have observed in the course of our work. While the presentation frequently touches on Smalltalk "motherhood", the principles themselves are more general and should prove useful in evaluating other systems and in guiding future work.
Jan 2 202412 Software Architecture Pitfalls and How to Avoid Them
Developing a successful software architecture is simple, but it’s not easy. Understanding QARs and then understanding and making the trade-offs that will maximally satisfy the QARs takes insight and experience, much of which has to be gathered through iterative experimentation on the architecture itself. The process itself is simple, but the trade-offs that need to be considered are often tough, and there are seldom easy answers.
Architecture Best Practices Design
Dec 18 2023