And you are here why?

You’d like to believe that the contents of your monorepo are well constrained, you’ve followed  Loose Coupling  principles thoroughly, and it’s  SOLID  as far as the eye can see. And yet,   yet , this happens It isn’t like it’s some  #CowboyDeveloper  deciding to go f**k around in the code-base, and send in  all  the changes to the 17 tickets that he (•) was working on at the same time. I mean of course yes, that happens. In this case though, it was that one change in a library module, that was needed, that trickled up through the code-base, and ended up affecting everything. We’re not perfect. It may have been “ SOLID  as far as the eye can see”, but it turns out that the bug in the library module was actually over the horizon, and yeah, it affected everything. Sigh. I know what  I’m  doing for the next 6 hours… (•) Yes. It’s always  He .

Abstractions are good, when it comes to software development . There are any number of reasons for this, from  Loose Coupling , to  SOLID , to, well, just google it if it isn’t already obvious to you. Let’s add a touch of nuance though, because, after all, Nuance  is  what we do in Software Development   . Abstractions are  mostly  good when it comes to software development . The key here is the ever-present tradeoff between Flexibility and Performance. Or, to put it differently, if you’re going through the “ Make it Work → Make it Right → Make it Fast ” sequence, and have somehow (hallelujah!) managed to get to the  Make it Fast  stage, well, this is almost exactly where the abstractions can start biting you in the butt. Sometimes that one optimization you need to make is hidden behind an interface, and you really don’t want to compromise the interface (because the abstraction  it  provides is ridiculously valuable everyw...

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

Do you know what your component’s dependencies are? OK, fine,   you   know, but does everybody else on your team know? Great, they know too. Now for the really important part — does what   you   know match what   they know? You’d be surprised how often that   semantic mismatch happens. The folks working on   component XXX   need to temporarily persist stuff, and use the postgres infrastructure that the   component YYY   folks are so conveniently running in production. Which is awesome, right up to the point that the   component YYY   folks finish their migration to ElasticSearch, and deprecate postgres… The moral of the story — document (and share!) the design assumptions behind the architecture across all your teams. Whats more, on a fairly regular basis, reassess these assumptions, and see if anything needs to be added, updated, or removed!

In todays episode of “ Lets Talk About Stuff You Already Know ” we cover  Loose-Coupling . The  baseline definition  is kinda obvious — it’s a system is which each component has limited knowledge (and use!) of the other components. That said, if that was the extent of it, I would just have linked to  the Wiki page , and have been done with it. The thing is,  semantics are important , and what the term means to me is not necessarily what it means to somebody else. Given that the most costly software issues tend to be the ones made earliest, it behooves you to limit misunderstandings in the  Design  stage! Consider a simplified take on the development cycle, viz.  Design → Develop → Test → Deploy . With a loosely-couple system, you can • Design  your component with limited involvement from other components. Whats more, you can update this design without  other  folks having to change  their  stuff. • Develop  y...