And you are here why?

/via http://www.commitstrip.com/en/2013/08/28/faut-que-jte-dise-un-truc/ Life on the Leading (and yes,  definitely  Bleeding) Edge means that you’re always working around that *one* feature that doesn’t quite work the way you’d like it to. Read this, and tell me if it sounds familiar — 1.  You start working on a new system. It’s important, so you can’t really just experiment with Bleeding Edge stuff, but you’ll use this relatively new framework (or library. or codebase. or whatever) that you really like. It’s been around for a while — not so long that it’s Old, and therefore UnCool — but long enough that it’s got most of the kinks worked out. Besides, it’s perfect for what you want to do. 2.  The thing is, it is  almost  perfect for what you need. There’s this one feature that you wish it supported, but you can work around. So you —  happily!  — work around that feature 3.  Over the next few months, it turns out that that one feature that you...

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 • 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 ...