Runtime and compile time

What do I mean by "obvious"?

I’ve received a few questions about Implicit and Explicit Coupling via channels other than the comments here. So in this and the next couple of articles I’m going to have a go at answering them…

Recently on a Slack channel somewhere in Manchester, someone asked:

I've always known the terms loose and tight coupling, is there any difference to implicit/explicit?

I was in the car somewhere and didn’t see the message for a few hours, but in the meantime Ross had replied:

Implicit coupling tends to reveal itself at runtime, explicit can be found at compile time

Up to now in these articles I’ve been deliberately vague about this. For example, in Coupling Between Types — A Retrospective I wrote:

if a change to something elsewhere in the codebase could cause this function to misbehave, that possibility should be obvious locally, within this function itself

The key word here is “obvious”, and I’m not ready yet to define precisely what I mean by it. In part, that’s why I’m writing this newsletter. I want to use these articles — and your feedback — to explore the concept of Implicit Coupling. I have no idea yet whether it will turn out to be useful or understandable, and that’s why we’re here.

As things stand right now, there is one very good reason why I wouldn’t want to directly associate Explicit Coupling with compile time: There’s no stable notion of “compile time” across the whole scope I want to consider. For example, with a melting ice compiler such as that employed for Eiffel, exactly when is the code compiled? Or what about coupling in CSS, or between CSS and HTML?

Nevertheless, Ross has a valid point: I’m proposing a new(-ish) way to think about the biggest problem in managing software maintainability, and yet I refuse to define my terms!

And that’s because there’s a second — and more compelling — reason that I don’t want to correlate explicit coupling with compile time: we haven’t yet explored enough examples to demonstrate whether such a correlation would be warranted.

My hope with these articles is that a deeper understanding of Implicit Coupling can be teased out by exploring examples, and until we’ve looked at quite a lot of them I don’t believe it will be possible to generalise. There’s a hand-wavy section towards the end of the draft table of contents in If this were a book... that talks about creating a catalogue of examples of implicit coupling in many different programming technologies. I believe that catalogue must be our starting point. It must be developed and explored as our first activity, before anyone can say whether Implicit Coupling is going to turn out to be a useful idea, and before anyone can look for the presence — or absence — of patterns that might lead us to more general and abstract statements.

It also seems possible that as we explore the topic we’ll discover that tools could be written to help us to “see” Implicit Coupling. As (I hope) I explained in Discount Rules, some Reflection, any such tool would have to be provided with an omniscient view of the code, and so any coupling discovered would be a function of the horizon of any such view. But again, we’ll need to explore the space in detail before any such opportunities present themselves as being possible or impossible.

As Brian Marick says: “An example would be handy right about now”. By creating that catalogue of examples — and counterexamples — I hope we can “test drive” into existence some kind of model of Implicit Coupling that will turn out to be useful.

Image of the Ideal Stamp Album by Karen Horton https://www.flickr.com/photos/karenhorton/4280318746

So for now I’m happy to continue saying that “explicit” is in the eye of the beholder.