What is Connascence? (Software Architecture Ep. 5)

Bryon Harris
Published in
5 min readJan 12


Developing a better understanding of connascence will make you a better software developer nearly instantly. It’s THAT important.

Indeed, connascence is a fundamental concept needed to understand distributed systems, how to prioritize refactoring, componentization, domain-driven design, modularity, and coupling.

Transcripts (the following transcripts are auto-generated and may have typos or inaccuracies):

now I know what you’re thinking miles

why can’t we just talk about the coolest

hippest new architecture that I can try

to use on the job yet and the thing is

we’ve talked about coupling we’ve talked

about cohesion we’ve talked about

modularity and the conversation would

not be complete if we didn’t cover this

topic which is Con Nations say it with

me con nasons what a weird pronunciation

of that word and I double checked that

is how it’s pronounced cognasance all

right let’s get into it

all right so what is Con nasons let’s

break down the word so we’ve got con the

prefix which means with or together

right and then we’ve got nascent which

means coming into life or being born so

cognacence means things that are being

born together coming up together and in

the programming sense it’s basically

used to describe two components where a

change to one of them would require a

change to the other in order to

maintain the correctness of the system

that is the definition that Meyer page

Jones put forth

um when uh he investigated coupling that

Jim weirich took forward in in his

description of a more modern concept of

of cognizance

now the reason you should be excited

about Khan Nations is because it gives

us a really measurable objective way to

know what to refactor First how to

prioritize refactoring code and that is

extremely powerful in a world where

often it’s hard to know what should be


um it tells us a ton about the system in

terms of the coupling it tells us what

is most likely to break if we change

something so this is very very important

and useful information

we’re gonna break conditions into two

different types static and dynamic

static is going to be source code level

coupling that is things that can be

discovered by Static code analysis now

Dynamic cognizance is going to be at

execution time coupling okay so that’s

going to be not discoverable by Static

code analysis static cognizance includes

cognizance of the name so two components

must agree on the name of the type they

must agree on the type of the meaning so

that this would be


for example like magic numbers would be

an example of cognizance of meaning

where you have like a number that’s

defined in your code rather than pulling

it in as an environment variable which

is something we always look for when

we’re trying to refactor and make better

code that’s that’s an easy type of

coupling you can get out of your code


and then uh condescence of position so

like what order are the parameters

coming into the function does it do

component multiple components rely on

that and then you can have cognations of

algorithm so are they relying on the

same algorithm is there some implied

coupling through the use of a given

algorithm so in Dynamic cognacence we

have the execution so if the order of

execution matters things are said to be

dynamically cognacent for example in

Express middleware where the order of

that middleware can matter you may see

that as a JavaScript developer


then you get into cognations of timing

um which for example can result in a

race condition if your components are

relying on the timing of certain events

happening then there’s con nations of

values so when the values depend on each

other for example

um if you’re doing some kind of

distributed database and you’re relying

on the same value being in all of those


um can you rely on that actually being

the case or if you’re doing some math

and you’re updating some value that’s

shared across something

you know this for example could happen

in JavaScript where you have some

variable that you’re changing the the

value of that and it’s getting

referenced in different places if you’re

relying on that then you’ve got some

Dynamic cognizance issue

um and then finally identity which

similarly would be if multiple

components are um relying on the same

entity I think it’s really important to

break Dynamic conditions into

synchronous versus asynchronous calls so

when we think of a synchronous call

between two components the first

component is waiting for the response

from the other before it can continue

this creates a dynamic cognizance that

means that those two systems

um component a and component B must have

roughly the same architectural

characteristics because if they don’t

then imagine that one is putting out a

bunch of calls and the other is not as

scalable and it can’t scale up to meet

that demand and you start getting

timeouts and your system starts breaking

down which is why typically we like to

refactor those examples of synchronous

cognizance into asynchronous cognizance

or the fire and forget Paradigm this is


the the component that’s making the call

can make that call it fires and it

forgets and then for example that may go

into some q and it um it gets taken up

by the other component as it’s able to

which means that they are not their

architectural characteristics are not

coupled in the same way so that’s a

that’s a really interesting kind of um

feature of dynamic cognizance so if you

go back to our discussion about

modularity you can see how cognasance is

something you may want to minimize

across component boundaries but that

within a component it actually makes for

a really nice module so

um we can Define the architectural

Quantum as a component that is highly


meaning it has high cohesion so you can

go and see my video on cohesion

um and so it has high cohesion and it


a high Dynamic cognizance within that


um synchronous Dynamic cognizance

um within that component

this means that it can be deployed

independently and with its own

architectural characteristics

we just don’t want that to be coupled to

other architectural quanta in such a way

that makes them actually one

architectural Quantum because that

coupling is so high so when you start to

get into distributed systems it’s

important to think of your assist your

components in terms of the coupling

within that bounded context so that you

know that when you deploy it and it may

have different architectural

characteristics it’ll still fulfill the

duties of the system requirements now if

you’re like me this whole idea of the

architectural Quantum makes you start to

think wait are all of the systems I’ve

built a single architectural Quantum

because they’re all coupled through a

single data source and the answer is

that if you’re using a single database

the answer is yes you’ve been working

with a single architectural Quantum your

entire career if you’re working with

distributed data in a microservices

environment for example

um then you’re going to have a system of

multiple architectural quanta which um

you know kind of opens up a whole world

for you

English (auto-generated)