“Loosley Coupled” does not mean “Easy to build”

The concept of “Loose Coupling” is great on so many levels. I’ve used it to describe different types of things in ideal worlds, but I’m starting to see that there is a lot of gray area there that can be maddening in real worlds.

Here is Wikipedia’s current definition of it:

“Loose coupling describes a resilient relationship between two or more computer systems that are exchanging data. Each end of the transaction make their requirements explicit and make few assumptions about the other end. Loosely Coupled systems are considered useful when either the source or the destination computer systems are subject to frequent changes.”

I’m working with a small team on a really fun web-based product that weaves lots of stuff together. The core app we’re working on has a very powerful layer of intelligence built into it, but it depends on a stack of data sources and rendering environments that are all partially isolated and not necessarily production-ready.

This means that we can’t really test the product end-to-end. It means there are several layers of troubleshooting that get added to each bug no matter how small. It means we have to fake a service layer here and there to emulate behavior.

I’m realizing now that “loosely coupled” means you have to think a lot harder about each move instead of just cranking out everything from scratch the way you want it to work.

Ultimately, the power of our platform services including things like scalability and user data management will accelerate this product’s ability to reach a more profound state of being than it could without loose couplings. But the cost of glueing all the things together in parallel means that we spend hours in meetings and constantly reshuffle our attack plan.

It feels like running through mid-court of a dodgeball game.