What happened to Connascence?

Those of you who used to read my previous blog, or who have attended my training courses and public workshops, will know that I espoused Connascence for many years. (If Connascence is a new term for you, read all about it here: https://connascence.io/.) And although this newsletter is only a few articles old I’ve already had a comment suggesting that Connascence is a more useful concept than Coupling. So why the switch? Well, it’s not really a switch so much as a change of focus. Let me explain…

Firstly, Connascence has a “scientific” aura. Many writers describe it as a ‘metric’ or as a ‘methodology’, and yet it is neither. I’m as guilty as anyone for propagating this point of view, I guess. I even made this handy graphic listing “the nine types of Connascence” and based on Meilir Page-Jones’ books:

This “list of 9” was, I think, originally intended as indicative. And yet it has become prescriptive: these are the kinds of Connascence and so this is what to look for in your code. (Yes, I’m partly responsible for that; and so now I want to restore some balance.) I’ve been involved in long debates about whether some particular example of coupling was an instance of Connascence of Algorithm or Connascence of Convention. I don’t think it matters. What matters is whether the coupling is slowing down development and/or causing defects (see my earlier article Surprises). And if this coupling is slowing us down, what matters most is how to change it so that it doesn’t do that any more. Connascence gives us no help here; almost nothing has been written about how to move from “this code exhibits Connascence of Execution Order” (for example) to “this code is much more habitable”. With Explicit Coupling I’m starting with the solution: make the coupling visible.

When we take the list of 9 as a static artefact it can seem to be complete in some sense; I’ve seen people talking about “missing” kinds such as Connascence of Schema, Connascence of Contract, etc. The list of 9 can definitely act as a reminder when looking for coupling in our code, but we should see it as simply a starting point, not as anything final. In this newsletter I will be talking about other ways of finding and visualising coupling, and we can explore together whether they replace, complement or enhance the list of 9. The list of 9 can sometimes feel like a recipe; I want to move past that and instead think about refactoring, with our goal being to improve our code’s habitability. I believe we need more fluid concepts than the list of 9 to achieve that.

Connascence is an abstract, academic treatment of coupling, initially described by Meilir Page-Jones as an attempt to apply earlier theories of coupling and cohesion (Yourdon, Constantine, etc) to object-oriented code. Connascence as a theory makes no statement about code habitability, or whether Connascence is or isn’t desirable. Yet the list of 9 types can make it seem as if any Connascence is a bad thing, to be avoided and removed. But coupling — and hence Connascence — is inevitable, indeed necessary. Without Connascence of Name and Connascence of Type our code wouldn’t compile or run! Connascence is — and I believe was always intended to be — an abstract framework for reasoning about object-oriented code. And yet much recent writing casts Connascence as “bad”, to be removed from our code. I want to step away from this by focussing first on the outcome: habitable code. I want us to acknowledge front and centre that coupling is inevitable and necessary, and focus instead on how to use coupling as a tool to help us improve our code.

By abstracting away the habitability and leaving only an academic treatment of coupling Connascence leaves us with something that has no shades of grey and little practical relevance to daily work. My hope is that this newsletter will address that problem by starting from the desire for habitable code and working back towards techniques for creating it from uninhabitable code. I want to focus on the end result and the process of getting there, rather than any abstract definition of good vs bad. So while Connascence may underpin some of what I’ll describe here, to focus on it would be to miss the point.

The term “Connascence” does have a certain aura, no doubt derived from being an unusual word outside of the realm of normal discourse. But honestly, I’ve been talking about Explicit and Implicit Coupling with software teams for a couple of years now and we’ve found that the terminology is just as clear, and possibly more inclusive. My experience of coaching teams in the XP practices over the last 2-3 years suggest to me that Explicit vs Implicit Coupling is a useful, pragmatic tool that works in everyday software development, whereas Connascence feels more like a book exercise and is difficult to apply during the regular flow of test-driven development.

If these arguments have gone some way to convince you that there’s more to refactoring than looking for Connascence, please subscribe and share this series of articles. And if they haven’t, well please stick around and help me explore Explicit Coupling, with a focus on solving problems in code instead of merely classifying them. I hope that this newsletter will form the basis of a new set of tools to not only show where to look, but also to give some ideas as to what to do about it.