June 5, 2024

It’s not about what’s better, it’s about what’s less worse.

Sup nerds, I’m back from DDD Europe! Still processing the conference and adjusting to the horrible jetlag but also itching to get writing again, so let’s go.

The opening keynote to the conference was called “Modern Tradeoff Analysis for Software Architecture”. It was mostly about the factors that went into whether you should split up services into microservices and glue them together. Unsurprisingly “tradeoff” came up a whole lot: between throughput and latency, between simple and distributed transactions, between stability and volatility, etc. At the end he gave the example of comparing a queue-based architecture (SQS) to a pub-sub topic-based architecture (SNS).¹ He said that the queues made it harder to add new services, but the topics make it harder to do access-control.²

That’s when I realized I’ve been thinking about tradeoffs all wrong!

See, normally I think of tradeoffs as framing two positive things, like saying “SQS has better control while SNS is easier to add new services”. Instead the speaker framed it as two wholly negative things, and the tradeoff is which negative thing you want less of. We can do this with any tradeoff, because any positive quality about X can be turned into a negative quality of Y. Instead of “X is faster, Y uses less space”, we can say “X uses more space, Y is slower.”

I don’t know if this framing was intentional on the speaker’s part, but I like it so much more. What’s the difference? Even if you pick the least-bothersome drawback, you still have a drawback. Going back to the SQS vs SNS example, let’s say you hate the how hard adding new services to SQS is, so you switch to SNS. Then you realize it hard to do access-control, and this is a worse problem than the SQS problem was. So the right tradeoff is to go back to using SQS.

But now it’s hard to add new services again. And that sucks! You don’t get to stop thinking about the pros and cons just because you made a decision. There’s still a problem you have to deal with.

Two rules of thumb

Rule one: after I make a decision about a tradeoff, I need a plan to address the negative consequences of my choice, in a way that doesn’t also add in the negative consequences of the other choice.

Rule two: this explains a lot of the movement (or more cynically, churn) in software tech. Even when we make the right choice overall, in the moment we’re still under a lot of pain, and so we look for new tools/technologies/practices that address the pain we currently feel.

Bonus rule: part of the reason we do Software Mimicry is to reduce the pain of a choice we made.

The conference talk was my last big project for spring. My consulting calendar is free so I’ll try to devote some time to my personal projects in “progress” (learntla updates, alloy workshop, logic book). It’s a little tough without a hard deadline!

No “things I’m curious about” because I’m still v. tired

If you’re reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

1. He used SQS and SNS because they’re the names of the AWS services. I’m going to use them as shorthands for the architectures because SQS is easier to write than “queue-based architecture”

2. I don’t know if this actually true, but I’ll go with it because that’s how he framed it.