---
title: Continued Learning - The Beauty of Maintenance - Kent Beck - DDD Europe 2020
disqus: pierodibello
---

###### tags: `coupling` `cohesion` `design` `agile` `kentbeck`

# Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020

https://www.youtube.com/watch?v=3gib0hKYjB0

{%youtube 3gib0hKYjB0 %}

## Public speaking
Nervousness (playing live on stage) or excitement (waiting to open the present at Xmas morning) both share the same sensations: you have to choose how you want to live that moment... you could choose nervousness or excitement. Choose excitement, the joy of discovering (see [A Soprano on her head](https://www.amazon.it/Soprano-Her-Head-Right-Side-Up-Performances/dp/0911226214)).

## Coupling and Cohesion

**Coupling** and **Cohesion** are foundational concepts, but everyone means something a little different.
People tend to use those two words to describe things that are not related to coupling and cohesion (and maybe we should find a proper word for those things, instead of using coupling and cohesion...).

The "Structured Design" book (by Ed Yourdon and Larry Constantine) introduced the concepts of Coupling and Cohesion.


Ed and Larry: *What are the common properties of programs that are cheap to change: are there any patterns?* 🤔

### Building sw is not like building a car

:computer: != :car:

Building sw is not like building a car: we cannot spend 70% of the budget on car maintenance, but on sw this could be easily true.
Sw changes as soon as it gets created and released in the hand of the users!

In XP, we say we want to spend 99% on maintenance: we'll just get it in production and then build it up from there 😀

### Coupling

#### The original definition of Coupling

Software is built out of elements (elements may be at different scales: from variables, to statements, functions, methods, components, repositories, to services).

If I have two elements, A and B, and I say that **"A and B are coupled"**

`A --- B`

this means that **if I change A I also have to change B**.

The original definition of coupling is:

:::info
**A and B are coupled *with respect to a particular change*
if changing A implies changing B**
:::

`Coupled(A,B, ∆) :: ∆A -> ∆B`


#### Coupling between services

If I have two **services** and one calls the other, they're not coupled by this definition (unless if I change one I have to change the other too)... they have some relationship though (are we missing a word here?).

:::warning
The key words when talking about coupling is **"...are coupled WITH RESPECT TO `<SOMETHING>`"**
:::

E.g. two services are coupled with respect to name changes of the parameters.

#### The Parallel pattern - making things worst and then making them better
To make a change without breaking other dependent elements, have two implementations of the same thing and slowly move from using the old one to using the new one. When finally nobody uses the old implementation anymore, just delete it.


"Isn't this weird?" some people think... _making things worst and then making them better_?!

No, it isn't

* life lesson #1 things always get worse before they get better
* life lesson #2 you can do it

#### Why coupling is important?

Because of cost.

:::info
The cost of software is roughly equivalent to the cost of change.
:::

That's why we spend most of the money of sw development on maintenance.

All changes don't cost the same amount...
:::info
The cost of change is roughly equivalent to the cost of BIG changes.
:::


we're gonna have
* lots and lots of small changes that are cheap
* few big changes that are really expensive

What makes changes really expensive is not just the change, it's the **"cascading", ripple effect** like in _I change this, so I have to change those too, so now I also have to change those, and now I have to change those, ..._


Complexity theory => power law distribution, like in avalanches or hurricanes.

The more changes we have:
* the more small changes we'll have
* the more big changes we'll have, that will compound and bring the cost of change higher

In sw, **what conducts the cost of a change is COUPLING** and its "cascading changes" effect.

A big percentage of cost of change is in the few big changes (the "tail" of the curve).


So, the less coupled your system is, the less likely the changes will propagate, the less extreme the cost of these most expensive changes will be, the longer you can last continuing to change your software.

:::success
Decoupling things reduces the cost of making changes over time
:::

Side note: there will always be some coupling in your system!

#### Coupling can happen anywhere!
Coupling is not just "this function call that function", coupling can happen anywhere!
There is a non-zero chance that any change you make is going to break something somewhere else... the more complex the system, the more likely this will happen.

True story at Facebook: two unrelated services hosted on the same rack, one changed its backup policy, this in turn saturated the rack network switch => these two services were coupled with respect to the backup procedures!

#### Principles to reduce coupling

At the level-code principles you can see the patterns in the ["Smalltalk best practices"](https://www.amazon.it/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X) and ["Implementation patterns"](https://www.amazon.it/Implementation-Patterns-Kent-Beck/dp/0321413091) books.

:::danger
The most expensive coupling is the coupling that you don't see!
:::
(like the two services sharing a rack switch).

Expert programmers have "good habits", like **don't use global state**, and **be explicit of the data that goes in and data that goes out** => you can see clearly what enters, what exits => it's then easier to identify coupling.

### Cohesion
(inverse of coupling?)


**The original definition of Cohesive:**
If I have an element E that have sub-elements, that element is **cohesive** to the degree that its sub-elements are coupled, meaning that if I have to change one of these sub-elements, I have to change the others sub-elements at the same time too.

**Putting together things that change together is a way of reducing the scope of coupling**, because the rippling effect will be localized in a single element, and it will be also easier to find where to make the change, because the elements to change will be in the same place.

#### Degree of cohesion
All sub-elements should be coupled to each other? Or it's enough to have at least SOME sub-elements coupled? It depends.
If all sub-elements are coupled, code will be easier to change.

For example, having two out of four sub-elements coupled seems good enough for a cohesive element, but it's then better to keep together the sub-elements that change together and separate those that don't.
You'll end up with a more cohesive solution, that will make changes easier, because you'll know that when you change one sub-element you have to change the other sub-element and you can forget the other sub-elements.


### Coupling vs Cohesion

Eliminating coupling is hard, improving cohesion is simpler!

:::info
There is always a trade-off between the cost of coupling ("rippling changes") and the cost of de-coupling. 🙅‍
:::

Since there is always some coupling in your system, you have to continuously balance between:
* **the cost of coupling** that you're experiencing because of the changes you have to do, and
* **the cost of decoupling** the system


> :question: what should be the "right" curve for the cost of decoupling? the light green one or the dark green one?

## Should I tidy first?
When should I decouple? Should I tidy first?
In front of a change I need to make, should I reduce coupling / improve cohesion first or just make the change to the ugly code?

This is a call that we - as engineers - have to make every time.

Coupling is a `n^2` problem: every element in your system can be coupled to every other elements in the system (where `n` is the number of services, repositories, variables, modules, classes, etc).
And `n` can be very large!

The cost of decoupling can be enormous.
The good news is that **you can always find elements to make more cohesive**.
And making code more cohesive (take things that are going to change at the same time and putting them together) can be done locally, without having to look at the entire system.

Extract method, make the change, inline (or not).

## Two style of designers: [lumpers and splitters](https://kentbeck.substack.com/p/lumpers-and-splitters)

* **splitters**: prefer lots of little pieces that interact with each others
* **lumpers**: prefer big giant elements (classes, tables, methods) so that they can see all at one glance

> see also https://kentbeck.substack.com/p/make-it-run-make-it-right

:::success
In order to reduce coupling over time, you may choose to create cohesion, because creating cohesion tend to reduce coupling.
:::

## Structural change vs Behavioral change (make the change easy, then make the easy change)

You have an idea, so you change the behavior to implement that idea.
But you also have to change the structure of the system in order to implement that idea.
And how the system is structured affects the cost of changing the behavior you need, because of coupling!

What do you do first then?

:::info
**Make the change easy, then make the easy change**
:::

You decide to *first* change the structure of the system in order for the change to be easy.
Making the change easy can be hard too, because you may need to do recursive things in order to make the change easy, just like the [yak shaving](https://www.urbandictionary.com/define.php?term=yak%20shaving).

You're spending energy and brain power on making the next change easy, not on making the change, and this could be hard to do for many devs, because they like the "tough job" and the pressure is on "I wanna see the next behavior change".

### Carefully separate structural changes from behavioral changes
Try this experiment: **[carefully separate structural changes from behavioral changes.](https://kentbeck.substack.com/p/structure-and-behavior-prs)**
Either do a structural change or a behavioral change, but not the two at the same time. And keep those changes separated (e.g. in separated pull requests).

Behavioral changes in general are IRREVERSIBLE, you have to be very careful.
Structural changes are REVERSIBLE (extract method -> inline method).
So you can apply different standards to very different sets of decisions.
> see also https://kentbeck.substack.com/p/structure-and-behavior

## Waterfall is coming back, kill it again (with fire 🔥)
Waterfall never works, it never did!

Traits of a *"waterfallish"* way of thinking
* big feedback loops
* not looking for / getting feedback as soon as possible
* specify all without getting feedback

Big feedback loops don't work because:
* you cannot predict the future
* making a change in the world cause the world to change, so the next thing will be different

So you cannot specify all the things, you have to do one thing, look for feedback, and then decide.

### Call a timeout
In front of a "waterfallish" thinking, let's call a timeout!
I'm not sure about what we did: let's implement something, let's put in front of people, let's see how they act, let's see what we learn and how this change our understanding, BEFORE taking the next decision.