Run your own Mastodon server to control your social media presence

Conway's Law (formulated in 1968 by Melvin Conway) says that a system's design is constrained by the communication patterns of its designers. Birgitta, Mike, James, and I discuss the meaning of this principle and how we've seen it play out in our careers. We talk about its impact on the concept of Microservices, the importance of aligning with business capabilities, and the role of the inverse Conway maneuver.

With the current uncertainty over Twitter, I'm starting to explore using Mastodon

Pretty much all the practitioners I favor in Software Architecture are deeply suspicious of any kind of general law in the field. Good software architecture is very context-specific, analyzing trade-offs that resolve differently across a wide range of environments. But if there is one thing they all agree on, it's the importance and power of Conway's Law. Important enough to affect every system I've come across, and powerful enough that you're doomed to defeat if you try to fight it.

Distributed systems provide a particular challenge to program. They often require us to have multiple copies of data, which need to keep synchronized. Yet we cannot rely on processing nodes working reliably, and network delays can easily lead to inconsistencies. Despite this, many organizations rely on a range of core distributed software handling data storage, messaging, system management, and compute capability. These systems face common problems which they solve with similar solutions. This article recognizes and develops these solutions as patterns, with which we can build up an understanding of how to better understand, communicate and teach distributed system design.

When faced with the need to replace existing software systems, organizations often fall into a cycle of half-completed technology replacements. Our experiences have taught us a series of patterns that allow us to break this cycle, relying on: a deliberate recognition of the desired outcomes of displacing the legacy software, breaking this displacement in parts, incrementally delivering these parts, and changing the culture of the organization to recognize that change is the unvarying reality.

James Shore's Art of Agile Development is my favorite single-volume book on agile software development. A reason for that is its serious emphasis on the technical practices that are essential to making it work effectively. James and I discuss the role of refactoring for software development, the nature of design changes we see, and how to break down big changes into small pieces.

The things I do to make Twitter useful and avoid the time-traps

An inception is an activity done at the start of a project to gather together the people involved and set a common direction and working style for the on-going work. The lean inception is a focused form of inception, which can be done in a single week. During this time we understand the key features and customers for the product, and build a canvas to formulate the characteristics of a Minimum Viable Product.

Infrastructure Platform teams enable organisations to scale delivery by solving common product and non-functional requirements with resilient solutions. This allows other teams to focus on building their own things and releasing value for their users. But nobody said building scalable platforms was easy... In this article Poppy and Chris explore 7 key principles which can help you build the right thing right. Spoiler: don't skip strategy, user experience and research.

Neal and I discuss the interplay between the patterns and practices that drive good software architecture.