So we should aim to eliminate dependencies. I guess that means our eventual goal is ZERO dependencies, right?

Wow, wouldn’t that be nice! In a perfect world…

Of course, short of selling all you own, and moving to the middle of nowhere to take up subsistence farming, that’s not really possible.

Every project we build has dependencies. At the most fundamental level, if you’re deploying to the cloud, you probably depend on Amazon, or Google, or Microsoft, to provide your cloud infrastructure. If you deploy to bare metal servers, you probably depend on the Linux kernel. Or maybe Microsoft Windows. And these in turn depend on the manufacturers who build CPUs, RAM chips, and some utility companies that provide eletricity, etc.

So what makes this type of dependency different, and apparently “non-evil”, unlike the problem of depending on another team in your organization?

To over-simplify: Temporality.

A dependency is a problem primarily when it’s a temporal dependency. That is to say, when we must wait for it.

Dependencies that are handled before we care, aren’t a problem. (Or at least aren’t the type of problem we’re trying to solve when we build cross-functional teams.)

If you have a peer team in your company that provides a dependency you care about… that becomes a problem when the work ends up waiting on them. If that team is always done with their part before the work is waiting on them, then it’s not a temporal dependency.

This is the promise behind the concept of a “platform team”. In fact, that’s the whole idea of AWS (and other cloud providers). These services provide dependencies that you and your team need… but in such a way that they’re always ready before you need them, so you don’t have to wait on someone to install a server, or provision a VM. It’s just… always ready.

If you’re working with dependencies, and you can’t eliminate them, can you decouple them from the temporality of delivery? Can you implement platform teams or other similar patterns?