Reducing Dependencies

I’ve covered loose-coupling before, and discussed systems where the components have limited knowledge — and use! — of each other. While the focus in that article was on semantics, let’s get a wee bit more specific, and look at what the actual dependencies we want to reduce are.

(And make no mistake about it — we want to reduce dependencies. The cartoon above isn’t really a joke, most — if not all — systems trend towards something that looks like that…)

Anyhow, when we talk about reducing coupling, we’re basically talking about reducing (or eliminating) one or more of the following

1. • Signal Dependency (“Disintermediation”): How dependent are your components on information (signals!) from each other? Are they capable of working on different things independently?
   As a really simple example, think of an “old-school” UI in which every time you do something, it needs to go to the server to validate the action, vs a “modern” PWA where everything is happening right there in the app.
2. • Computational Dependency (“Decomposition”): Can you run — or upgrade — individual components independent of each other?
   For example, do you need to bounce the database every time you restart the application?
3. • Time Dependency (“Asynchronicity”): Do components have to “wait” on each other to get their things done? Can they “fire and forget”? Or are they ok with “I’ll get back to you on this”? (•)
   The easiest way to think of this is email vs WhatsApp . When you send email, you implicitly know that it probably isn’t going to be read immediately. OTOH, when you use WhatsApp, the “double check mark” tells you whether they’ve seen the message.

Live these, breathe these, and internalize these.
And, as always,

be sure to document — and share! — the design assumptions behind the architecture across all the teams. Whats more, on a fairly regular basis, reassess these assumptions, and see if anything needs to be added, updated, or removed. And always remember, the focus here is on sharing the knowledge, not on keeping the assumptions static!

(•) There is an extreme case of Asynchronicity that you can characterize as Laziness — how long can you wait before you actually need to do something? An example for this would be that you probably shouldn’t go shopping for supplies till the guests have actually confirmed that they’re coming for dinner…