Velocity defeats itself. Get acceleration instead
what a spherical cow can teach us about task prioritization in software teams
architecture
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.
Stupidity can be a plus in corporations — but not in software development.
Functional stupidity is: don’t self-reflect, don’t ask why, and only think about what we ask you to think about. This can be good in corporate-land. It is a disaster for software.
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
Reuse
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