Every SaaS Integration needs an Upstream Point of Contact

Can you see a pattern in these examples? SendGrid sends emails for you. You provide it with a webhook URL.  It uses the webhook to “call you back” about what happens with those emails, like when they are dropped because your request was invalid. On AWS, you need to listen to an event bus if … Read moreEvery SaaS Integration needs an Upstream Point of Contact

Nonlinear increases in complexity make unification excruciating.

TL;DR: When you want to build one platform for all your lines of businesses: stop. Don’t. Build systems for each instead. Keep the integrated parts as small as possible. This minimizes costs, while enabling change. A global, unified platform to support all our lines of business! Doesn’t that sound glorious? CIOs puff out their chests. … Read moreNonlinear increases in complexity make unification excruciating.

Layers in software: from data to value

Then Back in the 2000s, we wrote applications in layers. Presentation layer, client, data transfer, API, business logic, data access, database. We maintained strict separation bet ween these layers, even though every new feature changed all of them. Teams organized around these layers. Front end, back end, DBAs. Layers crisscrossed the flow of data. Responsibility … Read moreLayers in software: from data to value

Change at different timescales

On recommendation from @mtnygard and others, I have acquired a copy of How Buildings Learn (Stewart Brand, 1994). Highlights so far: Buildings are designed not to adapt, but they adapt anyway, because the usages are changing constantly. “The idea is crystalline, the fact fluid.” They’re designed not to adapt because “‘Form ever follows function’ … … Read moreChange at different timescales

Hyperproductive development

TL;DR: the most productive development happens when one person knows the system intimately because they wrote it; this is in conflict with growing a system beyond what one person maintains. Let’s talk about why some developers, in some situations, are ten times more productive than others. hint: it isn’t the developers, so much as the … Read moreHyperproductive development

Code and Coders: components of the sociotechnical system

TL;DR: Study all the interactions between people, code, and our mental models; gather data and we can make real improvements instead of guessing in our retros. Software is hard to change. Even when it’s clean, well-factored, and everyone working on it is sharp and nice. Why? Consider a software team and its software. It’s a … Read moreCode and Coders: components of the sociotechnical system


Developers have a love-hate relationship with code re-use. As in, we used to love it. We love our code and we want it to run everywhere and help everyone. We want to get faster with time by harnessing the work of our former selves.And yet, we come to hate it. Reuse means dependencies. It means … Read moreReuse

Tradeoffs in Coordination Among Teams

The other day in Budapest, Jez Humble and I wondered, what is the CAP theorem for teams? In distributed database systems, the CAP theorem says: choose two of Consistency, Availability, and Partitioning — and you must choose Partitioning. Consider a system for building software together. Unless the software is built by exactly one person, we … Read moreTradeoffs in Coordination Among Teams