Without an event, no time passes. This may seem like an odd assertion. You may say, “I can see time passing all around me!” But how do you see it? Do you look at the ticking hands of a clock? In a mechanical clock, each tick is an event: when the tension on an escapement exceeds the friction between its prong and the gear, and the escapement knocks over to the other side with the familiar “tick.

​Architecture​ & Development Require​d Reading ​​Architecture Decision Records​ C4 Model​ (Note: we will only use the first 3 C's.) Accelerate​ ​​​​​Wardley Maps​ Failure Modes and Continuous Resilience Recomm​ended Reading The Principles of Product Development Flow​ Software Architecture in Practice Domain-Driven Design ​Data and Reality, 2ed (Note, the 3rd edition is not as good. Best to stick with 2nd edition.) The Phoenix Project - A novel about IT transformation with a devops flavor. ​The Unicorn Project​ - A followup to the Phoenix Project that looks more directly at development.

Shared State When programming distributed systems, the hardest kind of data to manage is shared mutable state. It requires some kind of synchronization between writers to avoid missed updates. And, after changes, it requires some kind of mechanism to restore coherence between readers. I previously wrote about that idea of a coherence penalty as it applies to humans. Following those lines, we might regard the system of development teams in an organization as its own distributed system.

An elegant design conserves mechanisms. It combines a small number of primitives in various ways. When I first learned about this elegant bit of design in Smalltalk-80, I laughed with delight. In Smalltalk, the primitives are “object” and “message”. That’s basically it – except for blocks, which we will see a little later. Behavior arises via objects sending messages to each other. In fact, Smalltalk doesn’t even need control structures in the language grammar.

Another quick post based on a Twitter exchange. (Maybe this will help save content from the ephemera of Tweets.) A short, incomplete list topics in networking that programmers should know about: ICMP messages Frame size and fragmentation Socket options Listen queue and behavior when full. All the timeouts and why they exist. When read, write, and connect calls block and why. When memory buffers are copied and how to avoid. A reference I love is the encyclopedic The TCP/IP Guide (note: affiliate link.

Way back in January, Sam Newman tweeted this (perhaps rhetorical) question: I was in the middle of creating this slide (wrt patch hygiene) and had to stop half-way through and ask myself - aren’t we all just making this worse? pic.twitter.com/fCTAYDc3Pn — Sam Newman (@samnewman) January 14, 2018 It got a handful of retweets recently, and I responded with: I've said it before, but each of these layers is another attempt to achieve isolation between apps.

Hat tip to Stuart Halloway… once again a 10 minute conversation with Stu grew into a combination of code and writing that helped me clarify my thoughts. I've been working on new content for my Monolith to Microservices workshop. As the name implies, we start with a monolith. Everyone gets their own fully operational production environment, running a fork of the code for Lobsters. It's a link sharing site with a small but active group of users.

The other day I tweeted that "Data is the New Oil." A lot of people retweeted, but a quite a few asked what I meant by that. I'll amplify a bit to explain the analogy. This ended up being a lot to unpack from a quick tweet! For quite a few years now, I've used Twitter as a way to scratch the itch of personal expression. A quick sound bite there, highly compressed and idiosyncratic was just enough to relieve the mental pressure.

This is a brief aside from my ongoing series about avoiding entity services. An interesting dinner conversation led to thoughts that I needed to write down. Amdahl's Law In 1967, Gene Amdahl presented a case against multiprocessing computers. He argued that the maximum speed increase for a task would be limited because only a portion of the task could be split up and parallelized. This portion, the "parallel fraction," might differ from one kind of job to another, but it would always be present.

This post took a lot longer to pull together than I expected. Not because it was hard to write, but because it was too easy to write too much. Like a pre-bonsai tree, it would grow out of control and get pruned back over and over. In the meantime, I delivered a workshop and spent some lovely holiday time with my family. But it’s a new year now, and January is devoid of holidays so it’s high time I got back to business.