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

Summary

In this insightful keynote, the speaker reflects on their first encounter with Domain-Driven Design (DDD), sharing anecdotes from the dot-com era. They delve into the nuances of software design, focusing on the importance of coupling and cohesion in maintaining a manageable codebase. The speaker emphasizes the need to make change easy by altering system structures to facilitate behavior changes, advocating for short feedback loops and the DDD community's role in promoting adaptive and responsive design practices.

Takeaways

• 🎤 The speaker emphasizes the importance of public speaking and overcoming nervousness by reframing physical sensations as excitement rather than anxiety.
• 📚 The speaker reflects on their first encounter with Domain-Driven Design (DDD) and the evolution of their understanding of DDD principles over time.
• 🔄 The discussion highlights the concepts of coupling and cohesion in software design, noting that these terms are often used with varying interpretations.
• 🔗 The original definition of coupling is presented as a relationship between software elements where a change in one necessitates a change in another.
• 💡 The speaker introduces the idea of using the 'parallel change' pattern to manage changes in systems with high coupling, allowing for staged updates.
• 📈 The cost of software development is likened to the cost of change, with coupling being a significant factor in the expense of making updates to a system.
• 🔍 The speaker discusses the subtleties of coupling, including unexpected forms of coupling that can arise in complex systems.
• 📦 Cohesion is described as the degree to which sub-elements within a single element must change together, promoting a more manageable change process.
• 👷‍♂️ The speaker advocates for making changes easy by adjusting the system's structure to facilitate future behavior changes, a concept they relate to the 'tidy first' approach.
• 🔁 The script touches on the cyclical nature of software development, where behavior changes lead to more behavior changes, influenced by the underlying system structure.
• 🚫 The speaker warns against the resurgence of waterfall-style development, advocating for the DDD community to uphold principles of feedback and iterative design.

Q & A

What is the main theme of the speaker's keynote at the conference?

The main theme of the speaker's keynote is exploring the concepts of coupling and cohesion in software design, and how these concepts relate to the cost of change in software development.

Why did the speaker choose such a generic title for his talk?

The speaker chose a generic title so that he could adapt the content of his talk based on the conversations and interactions he had with people at the conference.

What was the speaker's first introduction to Domain-Driven Design (DDD)?

The speaker's first introduction to DDD was through working with Eric Evans in 2000 on a project during the dot-com era, which involved planning for retail purchasing.

How does the speaker relate the concept of performance anxiety in music to public speaking?

The speaker uses the concept of performance anxiety in music to illustrate that the physical sensations of nervousness can be reframed as excitement, which can help in overcoming stage fright during public speaking.

What is the original definition of coupling as discussed in the 'Green Book' of structured design?

In the 'Green Book', coupling is defined as the degree to which a change in one element (such as a variable, function, or module) necessitates a change in another element.

What is the relationship between coupling and the cost of change in software?

The cost of change in software is closely related to coupling; the higher the coupling, the more likely changes will propagate and increase the cost of making those changes.

What is the speaker's view on the resurgence of waterfall-style development?

The speaker views the resurgence of waterfall-style development as a step back, despite it being practiced by smart people trying to solve real problems. He emphasizes that it doesn't work because it lacks the necessary feedback loops.

How does the speaker suggest separating behavior changes from structural changes in software development?

The speaker suggests separating behavior changes from structural changes by making them in different pull requests (PRs). This allows for different standards to be applied to reversible (structural) and irreversible (behavioral) changes.

What is the significance of the speaker's slogan 'Make change easy, then make easy change'?

The slogan emphasizes the importance of structuring the system in a way that facilitates easy changes. It suggests that developers should focus on making the process of change easy before implementing the changes themselves.

What is the '3x model' mentioned by the speaker and how does it relate to innovation?

The '3x model' stands for Explore, Expand, and Extract. It is a model the speaker observed at Facebook to describe how innovation happens, and it suggests a cycle of exploration, growth, and refinement in the development process.

Outlines

00:00

🎤 First DDD Conference Experience

The speaker expresses excitement about attending their first DDD (Domain-Driven Design) conference, reflecting on their initial encounter with DDD through a project with Eric Evans in 2000 during the dot-com era. They delve into the complexity of retail purchasing planning and share their experience of the dot-com crash. The speaker also discusses their approach to public speaking, drawing a parallel between stage fright and the anticipation of giving a keynote, highlighting the importance of reframing nervousness as excitement.

05:00

🎼 Overcoming Performance Anxiety

The speaker shares insights on dealing with performance anxiety, inspired by their background in music and a book titled 'The Soprano on Her Head.' They discuss an exercise from the book that involves recognizing the physical sensations associated with nervousness and excitement, suggesting that the perception of these sensations as nervousness is a choice. The speaker recalls a memorable instance from 1987 when they reframed their nerves into excitement before presenting with Ward Cunningham, which helped them overcome their anxiety.

10:01

🔍 The Essence of Coupling and Cohesion

The speaker delves into the concepts of coupling and cohesion, emphasizing their importance in software design and how they are often misunderstood. They recount their experience on a panel celebrating the 30th anniversary of 'Structured Design,' also known as the green book, which introduced these concepts. The speaker clarifies the original definitions of coupling and cohesion, explaining that coupling refers to the necessity of changing one element when another changes, while cohesion pertains to the interrelatedness of sub-elements within a larger element. They advocate for returning to these precise definitions to improve communication and understanding in software design.

15:01

🔗 Understanding Coupling in Software Design

The speaker provides a detailed explanation of coupling in software design, using the original definition that relates coupling to the necessity of making a change in one element requiring a change in another. They discuss the implications of coupling for the cost of software maintenance and how reducing coupling can decrease the cost of changes over time. The speaker also introduces a practical example of how changing a parameter name in one service can necessitate changes across multiple services, creating a distributed monolith and the challenges that come with it.

20:05

🛠 Techniques for Managing Change in Software

The speaker introduces a design pattern called 'parallel' to manage changes in software systems, which involves introducing a new element alongside the existing one to avoid the need for simultaneous changes across multiple services. They discuss the importance of staging changes to avoid deploying all modifications at once, which can be challenging. The speaker also touches on the broader life lesson that change often gets worse before it gets better, emphasizing the importance of embracing this process in software design.

25:05

💡 The Impact of Coupling on Change Cost

The speaker explores how coupling affects the cost of change in software development, explaining that the cost is often tied to the cascading effect of changes due to high coupling. They liken the distribution of change costs to a power law, where most changes are small and inexpensive, but a few are large and very costly. The speaker emphasizes the importance of reducing coupling to manage these extreme costs and to maintain the ability to evolve software systems over time.

30:06

🌐 Unseen Couplings and Design Principles

The speaker discusses the subtle and often unseen couplings in software systems, using an example of two services inadvertently coupled through a shared network switch. They highlight the importance of design principles that can help reduce such couplings, such as avoiding global state and being explicit about data flow. The speaker also introduces the concept of cohesion in relation to coupling, explaining how a cohesive element contains sub-elements that are all likely to change together, which can be beneficial in managing changes.

35:11

🔍 The Challenge of Cohesion and Coupling in Large Systems

The speaker addresses the challenge of managing cohesion and coupling in large-scale systems, such as those found at Facebook or Gusto. They discuss the difficulty of identifying what to decouple in a large system and the high cost of doing so. However, they also highlight the benefits of improving cohesion, which can be achieved by grouping elements that change together into their own elements, making it easier to manage changes locally without needing to understand the entire system.

40:12

🤔 The Tidy First Approach to Software Design

The speaker introduces the concept of 'tidy first,' where they advocate for improving the structure of the code before making behavioral changes. They argue that making changes easy should be the priority, followed by making the easy changes. The speaker suggests that programmers often focus on the immediate change rather than preparing the system to accommodate future changes easily. They propose a recursive approach to making changes easy by considering the system's structure and how it can be altered to simplify future modifications.

45:12

🔄 The 3x Model: Explore, Expand, Extract

The speaker presents a model for innovation that they observed at Facebook, which they call 'Explore, Expand, Extract' (3x Model). They discuss the resurgence of waterfall-style development and criticize its ineffectiveness, despite being adopted by smart people trying to solve real problems. The speaker emphasizes the importance of feedback loops and the need to avoid long feedback cycles, suggesting that the DDD community is well-positioned to counteract the tendency towards waterfall development by insisting on shorter feedback loops and iterative refinement.

50:13

⚠️ The Resurgence of Waterfall Development

In the concluding remarks, the speaker warns against the resurgence of waterfall development, which they describe as a cycle that needs to be stopped. They express concern over the return of long feedback cycles and the lack of shame associated with having large specifications without feedback. The speaker calls for the DDD community to leverage its analytical strengths to resist this trend and to advocate for shorter, more iterative feedback loops to ensure that software development remains adaptive and responsive to change.

Keywords

💡DDD (Domain-Driven Design)

Domain-Driven Design (DDD) is a software development methodology that emphasizes the importance of the domain model, the model of the subject area of the problem space, in the design and implementation of software. In the video, the speaker reflects on his first encounter with DDD and its influence on his approach to software design, highlighting the community's evolution and practice over the past 20 years.

💡Coupling

Coupling refers to the degree of direct dependence between software modules; a measure of how interconnected they are. The script discusses the original definition of coupling from structured design and its importance in software design to reduce the cost of change. The speaker uses examples from his experience to illustrate how changes in one part of a system can necessitate changes in another, affecting the system's maintainability.

💡Cohesion

Cohesion is the degree to which the elements inside a module or component are related to each other. The video script explains that high cohesion means that if one element changes, all related elements must change together, which can simplify the process of making changes. The speaker contrasts coupling and cohesion, emphasizing the value of reducing the former and increasing the latter for better software design.

💡Change Management

Change management in the context of the video refers to the strategies and practices for dealing with modifications in software systems. The speaker discusses the cost of change and how it is closely tied to the concepts of coupling and cohesion. By managing how changes are made, particularly through reducing coupling and increasing cohesion, the impact and cost of future changes can be minimized.

💡Public Speaking

Public speaking is the act of performing a speech to an audience, which is a skill the speaker discusses in relation to handling nervousness and framing emotions. The video script shares a personal anecdote about the speaker's approach to public speaking, using the concept of excitement over nervousness to manage performance anxiety, which serves as a metaphor for handling challenges in software design.

💡Feedback Loops

Feedback loops are the process of receiving and incorporating responses back into the development cycle. The speaker criticizes the resurgence of long feedback loops, akin to waterfall development, and emphasizes the importance of short, iterative feedback to adapt to changes and improve outcomes. The video encourages the use of feedback to inform design decisions and avoid the pitfalls of rigid, long-cycle development.

💡Waterfall Model

The waterfall model is a traditional software development process that moves sequentially from one phase to the next without iteration. The script points out the resurgence of this model despite its known limitations, such as the inflexibility to changes and the lack of early feedback incorporation. The speaker calls for the DDD community to counteract this trend by advocating for more agile, feedback-driven practices.

💡Design Patterns

Design patterns are reusable solutions to common software design problems. The speaker mentions his work with Eric Evans and the development of design patterns in the late 1980s. The script uses design patterns as an example of how the speaker and his colleagues approached complex problems in software design, emphasizing the importance of reusability and modularity.

💡Refactoring

Refactoring is the process of restructuring existing computer code without changing its external behavior to improve nonfunctional attributes of the software. The video script describes a student's refactoring process, illustrating how creating cohesive elements can simplify the task of making changes and highlight the importance of this practice in software maintenance.

💡Software Maintenance

Software maintenance involves modifying a software system after it has been delivered to correct faults, improve performance, or add functionality. The speaker discusses the high costs associated with software maintenance, particularly due to the cascading effects of change when coupling is high. The script emphasizes the need for design practices that reduce these costs over time.

💡Tidy First

The concept of 'tidy first' suggests improving the structure of the code before making functional changes to simplify the process. The speaker introduces this idea in the context of writing a book and discusses it as a strategy to make future changes easier. The script uses this concept to highlight the importance of considering the system's structure in software design and development.

Highlights

Introduction to the speaker's first DDD conference and their initial exposure to DDD concepts in 2000.

The speaker's reflection on the intersection of their work and DDD, and how they have been informed by DDD without strictly following it.

The importance of public speaking and overcoming performance anxiety by reframing nervousness as excitement.

The concept of coupling and cohesion in software design, and their foundational role in the work of software designers.

The original definitions of coupling and cohesion from the 'Structured Design' book and their precision in describing maintainable software.

The evolution and misuse of the terms 'coupling' and 'cohesion' over time, leading to confusion in the software community.

The practical implications of coupling on the cost of software maintenance and the importance of decoupling to reduce change costs.

A real-world example of service coupling through parameter names and the challenges it presents for making changes.

The 'Parallel Change' pattern as a method to decouple services and manage changes without simultaneous deployments.

The subtle nature of coupling and the potential for unexpected 'action at a distance' effects in complex systems.

Strategies for reducing coupling, such as avoiding global state and being explicit about data flow in code.

The definition of cohesion and its role in reducing the scope of coupling by grouping elements that change together.

The benefits of creating cohesive elements for easier maintenance and the practice of 'cohesivating' code for clarity.

The distinction between 'lumpers' and 'splitters' in design philosophy and the speaker's preference for smaller, interacting pieces.

The importance of making structural changes before behavior changes to facilitate easier future modifications.

The '3X Model' of explore, expand, extract as a framework for understanding innovation in software development.

A critique of the resurgence of waterfall-style development and the need to counteract long feedback cycles with shorter, iterative processes.

The unique opportunity for the DDD community to advocate for shorter feedback loops and iterative development practices.

Transcripts

[Music]

thank you very much

it's very bright up here in case uh you

didn't uh

pick that up right away i'm i'm so glad

to be here

uh i have this is my first ddd

conference of

any sort i was reflecting

on my uh i

sort of my world and the ddd world sort

of bump into each other but

uh but don't really overlap a whole lot

i was thinking about

when i first heard about ddd

um i had actually worked with eric

uh in 2000 um

and i'm not going to ask who here was

born in 2000 because it'd be too

depressing

um and we we worked on a project

that also included some other uh

notables this was the the whole dot-com

era when we were all going to get rich

didn't didn't happen um

and uh it was a interesting domain

the domain was uh planning for retail

purchasing which

it's one of those things where you say

how many times have i said this as a

programmer

how complicated can that be and the

answer is always

is really complicated but

uh the team and and eric included really

dug

into what it meant to do a better job of

retail purchasing

and then the dot com crash happened and

everybody scattered to the winds

but that was the first introduction that

i had to it and then when the book

came out i read it and

thought hmm interesting ideas it's a

little different than my

approach to it but i'll be informed by

this in the future but i've never been a

follower or an applier of ddd

like straight out of the book so it was

interesting to get

for me to get this invitation and have a

chance to come and see

what had happened to the community and

the community of practice

over over the past 20 years

extreme programming uh has its own

community practice it's also

grown and adapted um i had a

conversation with eric

a couple of days ago about our different

approaches

to our community so he has stayed very

involved

i've kind of pulled back and done other

things

and uh so it's not often you get a

chance to talk to somebody

in in that similar kind of situation

having started something

having seen a big community grow and

well how do you manage that

as somebody who likes to start stuff

and isn't so good at finishing things

that would be me

so um when i got the invitation

to come and speak i thought what in the

world am i going to

uh to talk to you folks about i thought

i know what i'm gonna do

i'm gonna have a title that's so generic

that i could fit

absolutely anything into it

and then i'll just go talk to people and

i'll see

what it is i think i need to say given

the people that i've talked

to and so that's what i'll be doing um

i don't i can't you'll see in a second i

hand draw my slides i don't have

prepared slides so

i have an opportunity to kind of come up

with

things in the moment which i really

appreciate and uh

i hope that you will too and and if you

don't

you'll probably tell me about it so

that's okay

so um first thing i wanted to share

was uh it's not about programming at all

it's about

public speaking somebody asked me in the

elevator this morning

are you getting nervous about giving

your keynote

and i said well i wasn't until you asked

me

so no that's not what i said it's not

true but it would be a really good

response

so no what i said was uh um

no not really but there's actually more

to this story

there's a reason that i don't get

nervous when i speak

when i was in college the american

school system is

weird like everything american but one

of the things about it is you don't get

stuck in a track i think there are

educational systems where

very early you decide what you're going

to study and that's the one thing that

you study and you

stay focused on it in america is a

little loosey-goosey so

my first year i was a computer science

student

the second year i was a music student

because of course

and then i missed programming so then i

was a computer science student and then

i was a music student and i did my

senior recital

then i did my master's in computer

science and i just ended on the wrong

year

so here i am speaking at a computer

conference

so one of the things about music though

is you have to deal with performance

anxiety everybody feels some anxiety

around performance

and uh there's a beautiful book called

the soprano on her head

about dealing with performance anxiety

and the

the story from the title is a there was

a soprano

had a beautiful voice had so much

anxiety she just couldn't sing anymore

so the

teacher had her stand on her head and

sing

and it was just beautiful again like all

of the

anxiety went away of course she couldn't

do that on stage because that would

really look weird but

it was it was it's like a an example

like no you

you can still sing that's the as a

musician you're like

maybe my fingers won't work this time or

something like that

they usually do so that's okay but there

was an exercise in that book

and it went like this it said imagine

yourself going up on stage

and performing now take an inventory of

your physical sensations at that moment

your stomach's queasy your palms are

sweaty

your breathing is up in your chest and

shallow

okay so that's what that's what

nervousness feels like right

now imagine yourself christmas morning

as a kid you're about to go in and open

the presents

imagine that moment and take an

inventory of your

physical sensations at that moment

your palms are sweaty your stomach's a

little queasy

you're breathing shallow high up in your

chest

and you're excited so

the same sensations you say well i'm

feeling

nervous that tag of nervousness applied

to those sensations

is a choice that you make and you could

say

i'm excited at that moment now then i

remembered

the first time we ever uh ward

cunningham and i ever presented about

patterns

1987 we're in a workshop

um we had done our first experiments

with patterns

things had gone exceedingly well we had

a little write-up

and i was gonna get up and present and

around the table were

all the heavy hitters of the day

grady booch was there a very young

jeanette wing was there adele goldberg

and i was just getting nervous as i'll

get out my

my time slot was in the afternoon of

course so i had

all day and i remember about mid-morning

i was just getting exhausted because i

was

i was feeling so so nervous

and then i remembered this book and i

said to myself

i am really excited

and the the negative experience of all

of those

physical sensations just went away

i and it was just a change of my frame

so in answer to the elevator question

are you nervous no i'm excited

i feel some of the same sensations as

when i feel nervous

but i just choose to frame them as wow

i've got something to talk to you about

that i really want to talk to you about

so now if you don't

care at all about the technical content

i've just given you something that you

can take away and use regardless of

of what else it is that you do you're

welcome

okay on to the geeky stuff

so here's what i noticed

most about the conversations that i've

had over the last couple of days

there are a lot of people talking about

coupling and cohesion yeah

important concepts really the foundation

of the work we do as software designers

but the other thing i noticed is

everybody means something a little bit

different

when they say coupling and cohesion

sometimes it's a big concept

comes out of a small concept it goes in

slightly different directions

maybe 10 years ago i was on a panel

celebrating the 30th anniversary of the

publication

of structured design the green book how

many people have read structured design

okay cool the rest of you are in for a

treat

this is a book that ed jordan

uh a blessed memory and larry

constantine had written

describing their experience with a whole

range of software

written in the early days of programming

they what they did was they looked at

the software and they said

uh of the programs that were hard

to change what features do they have in

common and of the programs that were

easy to change

what features did they have in common

can we see any patterns

in how the software is constructed and

the answer was

yes and they came up with these concepts

coupling and cohesion

just to describe the common properties

of programs

that are cheap to change now back in the

early early days

the thought was that we would build

programs

and then just run them like uh

manufacturing you build a car

yeah maybe there's a little bit of

maintenance but you don't like rebuild

the car

now it turned out the software wasn't

like that we fought against that for a

long time

you know people would say i remember the

breathless we spend

70 percent of our development budget on

maintenance

isn't that awful doesn't that show what

a horrible job we're doing

and that's true if you had a car and you

spent seventy percent

thirty percent buying the car and

seventy percent maintaining it

you would not be a very good car but the

thing about software is

the very uh presence of the software as

soon as the software comes into being

the needs that it addresses change

so by its very nature software changes

itself you know you people see

some feature and they say oh i'd like

this other feature too they would

never have thought of that until they'd

seen that first feature

that was a big surprise so

these concepts of coupling and cohesion

were laid out very precisely

in the green book the structured design

book now

i had had structured design as a

textbook when i was in college

and so when i went to sit on this panel

i

realized that i should actually read the

green book

for the first time because you know it

was a college text it's not like i read

it

so i read it and i was just i was so

excited i mean there's some weird stuff

in there like a

very thoughtful discussion about

assembly language versus higher level

languages

you know which was an open question at

that time

and and something about punched cards

and paper tape and i'm like

so that part aged

quickly but the part that didn't age

at all was were these concepts of

coupling and cohesion and the

definitions are very precise in that

book

since then we've come up with other uses

for those words so what i'd like to do

is go back to those original definitions

and say here's

a meaning here's a concept

of coupling in this very particular way

i'm talking about it

and and you can apply whatever word you

want to

to to it but that concept is really

valuable and important

so we should separate that i think this

is the

message i bring to you separate that

concept from other concepts that we may

also apply the word coupling to

we should probably find other words for

those things because this thing i'm

talking about is very important

and worth focusing on as a designer

so uh

first software is built out of elements

and when i say element i mean things at

all different scales

so variables or elements and statements

or elements and expressions or elements

and functions and classes and modules

and services all these things are

elements repositories are elements

so when i say

i have two elements a and b

and i say that they're coupled what does

that mean

so it means

that if i change a

i also have to change b

so here's the in in something that looks

a little more like a

a mathematical notation

a and b are coupled with respect to a

particular change

so coupling is always with respect to a

particular change

if changing a

implies changing b

that's the original definition of

coupling

so if if i have two services and one

service calls the other

those services are not coupled by this

definition they have some relationship

and we should have a word for that

relationship but it's not coupling

unless changing one service means that

we have to change the other service

too in order for the system to stay in a

in a working state

so an example that came up yesterday in

conversation was

here i have a service it takes in some

some parameters and there's a parameter

a

and a parameter b and i want to change

the name of b

to c but i pass

this to another service that expects

parameters a

and b and connects it i think the number

that was quoted to me was seven

this thing is passed through seven

layers of services

all of which expect the names to be

sorry a

and b

so these services are coupled with

respect

to name changes of the

parameters i can i can go

inside of a service i can go inside this

service and make all the changes i want

as long as i don't change the name of

the parameters neither the other

services have to change

so uh for those kind of changes there

the services aren't coupled but for

purposes of

of these names that they are coupled

and the complaint was wow if i have to

change one

then i have to change all of them and my

best

bet is then i have to deploy all the

services at exactly the same time and

make sure there aren't any requests

in flight so

like it and you you have a distributed

monolith

which is worse than a monolith

um so how would you

how would you go about making this kind

of change so

in my kind of design world i use a

pattern called parallel where you have

briefly you have

two implementations of the same thing so

if i want to change b to c

i'm going to add a c here and make sure

that always contains the same value as b

now i can deploy this nobody else is

looking for c so they don't care

then i can add

c here and now i can start using c

because i know it has exactly the same

thing as b

and as soon as i'm done with that as

soon as i know that this service doesn't

use b

anymore to read it i can stop passing it

then i can make this change too so i

don't actually have to deploy

all of these changes at exactly the same

time

by going through a little bit of this uh

making things worse and then making them

better

i have a chance to uh decouple the ch

changes i can stage the the changes

so that's a trick that always seems to

bother a lot of people

because it makes things worse i have

duplication i have more duplication

and then it makes things better but

there is

another life lesson for you rule number

one is

things always get worse before they get

better and rule number two is you can

you can do it that's uh so

i thought this was going to be a

programming talk with some

little life lessons and it may be the

other way around by the time we're done

but we got a half an hour so let's see

what happens

okay so that's coupling coupling means i

have these two

elements if i change this one i have to

change that one too

why is that important it's important

because

uh cost the cost of software

is roughly equivalent to the cost

of change

that's that observation about we spend

most of the money in software

development on maintenance

which is just in the xp world we took

this

entirely all the way and said instead of

spending

70 on maintenance what if we spent 99 on

maintenance that seems like a good

number

we'll just get it in production and then

build it up from there and then we're

mostly making changes but

the cost of change all changes don't

cost the same amount

the cost of change is approximately

equal and i'll explain why in just a

second

to the cost of big changes

and what do i mean by big changes

if you made a histogram of the cost of

changes this is the count of the number

of changes that you make

and this is the cost

that's supposed to be a euro sign

the minus of handwriting slides is my my

drawing handwriting sucks so

oh well so if we make a histogram what

it's going to look like

is this

we're going to have lots and lots of

little changes that are cheap and we're

going to have a few

changes that are really expensive what

are those

what's the nature of those changes

here's where coupling

as defined just here is really helpful

what makes changes really expensive is

not

just the change it's i change this

so i have to change those so i have to

change

those so i have to change those

it's this cascading effect now if you

looked at complexity theory

you're going to recognize a power law

distribution here

and it's the exact same mechanism

as causes avalanches and hurricanes

you know most avalanches is is just one

snowflake

falls over and that's it and nothing

else happens

but there's a non-zero chance that one

snowflake falling over is going to cause

two more snowflakes to fall over

and each of those has a non-zero chance

of causing two more

and more and more so if you make a

histogram of the size of

avalanches most of them are just going

to be one snowflake

falling over and that's that and there's

a bajillion of those

happening all the time and you don't

really notice

but you notice the one that comes

sweeping through the village

and wipes everything off the map and

those happen

every once in a while the more changes

the more extreme both of the ends of

this are going to be

so when we have way more changes we're

going to have many many more small

changes

and the most expensive change is going

to be much much more expensive

in software what conducts

the cost of of a change is exactly

coupling

if a and b are coupled then when i

change a i have to change b

and if b is coupled to c and d then i'm

going to have to

change c and d and and and and and

thing about power law distributions is

a big percentage of the cost is in this

tail

even though this is a small number of

changes

in the absolute number the cost of that

compared to the cost of all the rest of

it that

tail is really expensive so

coupling is important because

the less coupled your system is the less

likely the changes are to propagate

the less extreme the cost of these

most expensive changes is

the longer you can last uh

continuing to change the software

so that's where that

definition of coupling gets us it's

important because

decoupling things reduces the cost of

making changes

over time a coupling can be uh

can be quite subtle uh i was at facebook

for seven years if you feel the need to

blame me for

like the destruction of democracy go

right ahead

um whoops

[Applause]

i remember once there were two services

now you might think well coupling that's

like if this function calls that

function

and they're coupled with respect to the

parameters to the functions that

okay that's fine but if i have two

services

that have nothing in common then they're

not coupled right

well no there's a non-zero chance that

any change you make is going to break

something

somewhere else and the more complicated

the system

the more likely that you're going to

have these crazy action at a distance

effects so there were two services

they happened to be deployed on the same

physical rack

so each uh computer has its own network

interface card

they all flow up to a switch on the top

and network switch on the top of the

rack

so one of the services changed its

backup

procedures to do all the backups at once

once a week and

that saturated that switch that rack

switch

the other service suddenly couldn't

communicate to the rest of the world

and it failed but

so these two services are coupled with

respect

to changes to the backup procedures

who knew right everything

can be coupled to everything else

and the bigger and more complicated the

system

the more likely you are to find these

kind of weird

action at a distance couplings and then

what do you do

so as a designer

there are some principles that you can

use

that help to reduce that kind of

coupling

the principles at the very finest grain

at the level of code are the sorts of

things that i wrote about in the small

talk best practice patterns

and then the java version of that the

implementation patterns book

which is just here's some habits

that expert programmers use

so that they communicate to other

programmers

the most expensive coupling isn't the

coupling that you

that you actually see it's the couplings

that you

don't see where like this these two

services sharing a rack switch

that's coupling nobody even knew existed

until there was a disaster

so expert programmers just have some

habits

at the at the lowest layer

like not using global state is a really

simple one just be explicit about the

data that goes in and data that comes

out

and if you're explicit about the

as my father would call them the

gosintas and the gazotas

then if you want to analyze the

situation you can

see okay here's what goes in here's what

comes out i'm not making any changes to

global state that's just a habit

if you can follow that habit it'll be

easier for you to identify coupling

so

so the there's a there's an

inverse of coupling so this other word

cohesion that people talk about

yeah and it's another word that has

in the original definition has a very

precise definition but that's not a

definition that

seems to have carried out over time

so here's the original definition of

cohesion

if here i have an element

and it has sub elements

this element e is cohesive

to the degree that its sub elements are

coupled

that means is if i have to change one of

these

i'm going to have to change all the

others at the same time

that makes e cohesive

now i read this in the green book

i'm like well isn't that bad to have all

of your

sub elements coupled to each other

and as always the answer is compared to

what

if let's say we have

a another situation

i think of these things kind of an

abstract way

let's say i have these two elements are

coupled but these

others other two aren't and i need to go

make a change to e

so i so i make a change to this element

so i

make a change to that element but i'm

gonna have to at least look at these

others

let's say this is four functions in a

file and i if i change

one if i change the writer i have to

change the reader two and then there's

some other functions and i don't have to

touch those

now i might say well that's good that i

only have to look at part of this

file in order to make the changes but

there's an even

better solution which is

to have this element be broken into two

where these things are coupled with

respect to the change

and i don't have to even think about

this part

now this uh what e sub 1

this is more cohesive

than e was originally because if i

change

one of these i'm always going to have to

change the other

and here's the beauty of cohesion like

eliminating coupling is hard

always you have this trade-off do you

know this the international

symbol for trade-offs

yes some places if you walk around and

you go ah

other people will flash that sign back

to you and

it's what geeks do instead of being cool

come on

so there is always a trade-off between

the cost of coupling

the cost of coupling is these rippling

changes

so you got that cost and if you have a

lot of coupling then the cost of

rippling changes is really high and if

you have

hardly any coupling at all then the cost

of rippling changes is low

but you also have the cost of decoupling

and they'll always be some coupling in

your systems

if you think there isn't any coupling

today tomorrow somebody's gonna ask

for some change to the system that will

reveal oh we do have coupling here after

all

so you're always as a designer you're

always

balanced i was going to say precariously

balanced but it's not really precarious

it's just like this is what we do

you're always balanced between the costs

of the coupling that you're experiencing

because of the changes you're having to

make

and the cost of decoupling and this is

these this is this moment where you say

i'm writing a book right now called tidy

first question mark

because all developers all the time

have this experience multiple times a

day this code is ugly

but i have to change it should i tidy

first

and that is exactly this moment of

software design where you're saying

okay there's there's some kind of i can

either reduce coupling or improve

cohesion

but do i do that or do i just make the

change to the ugly code

and it's a legit trade-off you can do

the one you can do the other

and you have to that i mean that's why

you get paid as a designer you

you have to make this call about what

you're going to do what you're going to

do

so here's the beauty about co of

cohesion

coupling is a n squared problem you have

n

elements they could all be coupled to

all the other n

elements in your system and that

n gets to be really large if you're

talking about facebook scale

or even my current employer gusto

where we do small business payroll and

benefits in the u.s

turns out there's lots of small

businesses

also turns out that tax authorities

and benefits providers have no incentive

to make

things simple so they're they're just

spewing complexity

and the beauty of of what we do at gusto

is we take that complexity and we give

the employer

and their employees a simpler view of

what it means to get paid

we make sure that forms get filed on

time and all that

but in order to digest all that

complexity is really really hard

and no matter how good you make the code

some joker in uh the oregon

workers compensation tax authority

is going to send you a new set of of

specifications for the new regulations

for

if you have more than five employees

which you think would be simple to

calculate but it's not

then you have to deduct this percentage

which you would think would be simple

but it's

not and then six months later they say

oh wait sorry we realized that what we

sent you was impossible to implement

so here's the new regulations

and here's how you're going to

retroactively apply them to all of the

forms that you already oh my lord

all of our data fits on a thumb drive

all of our customer data

carrying around in my pocket the

complexity is all in this

incredibly complicated rich domain

and number two we can't screw up at

facebook i worked on facebook messenger

for quite a while

and he always had some slack you know

just like no this isn't going to work

ah that's fine the little button that

says uh i was unable to send

try again you know that was always an

option and we don't have that option at

gusto

it's not like uh i was unable to make

things right with the irs for you

try again

does not work that way um

so what we do really matter and and if

we screw up badly enough

we literally can go to jail i mean we

can go to jail

not our clients so

um we have this big domain we have a

bunch of code to support it

which is grown organically people use

organic as some kind of pejorative

some kind of a oh this system just grew

organically

what is your other option

i mean we're all carbon-based life forms

right so

i don't get it anyway where's

what was i talking about i'm gonna get i

have four topics to discuss and i'm

gonna get through one of them today

so um coupling and cohesion i think i'm

almost there

here's the thing about cohesion though

coupling is this n squared problem and

you think about n

at a place like facebook or and at a

place like gusto

the number of repositories

and services and functions and

variables and database tables and and

and

is very very large that n is big

and then every a change to every single

one of them

could break every single other one of

them in some way that

is going to really surprise you at 3am

so

that's an intractable problem as a

designer

you don't get to work from a clean sheet

of paper you

you walk in and you've got a system and

it's already running and you need to

make it better

in some kind of way how do you reduce

coupling you remember that cost of

decoupling over here

that's really really enormous so it can

be

challenging it can be nearly impossible

as a designer to identify

what you even want to decouple

but here's the good news you can always

find things to make more cohesive

seeing things that are cohesive that is

that are going to change at the same

time

and putting them in their own element

that's something you can do just

analyzing locally you don't have to know

about

all of everything i realized

this as a habit when i watched one of my

students

refactoring he needed to change two

lines of code in the middle of a big

function

and he the first thing he did just as a

reflex didn't even

think about it he extracted those two

lines

into their own helper function he

changed the two lines he made sure that

the tests

passed and then he inlined that little

helper function back into the original

i thought wow that's a that's a waste

that's like

you could have just edited those two

lines in the middle of the function

but instead he created a cohesive

element

this function that would have to the

whole thing would have to be replaced if

any of the statements in it

changed all of the statements and it had

to change and then

that was a much easier task what are the

what's the state that i have to worry

about while i'm

in these two lines and i don't have to

think about all the stuff that came

before

all the stuff that comes after all i

have to think about is

what goes into this and what needs to

come out and that's

easier that's a cohesive element edit it

boom and then and then you can inline

it again or not your choice but that

moment of

now there's not a good verb for this so

i've invented cohesivating

which somebody's going to come up with a

better option than that it's

is it maybe this is a an application of

cunningham's law

you know cunningham's law if you want a

good answer to a question

on the internet you don't post the

question you post a bad answer

and somebody will correct you

most often a guy but

that's a whole different set of

political problems okay

um

no it's a guy if you don't want the

answer changed

um so you you can always make things

that are cohesive

uh it turns out there's two styles of

designers

lumpers and splitters you know about

this

i am definitely a splitter i like lots

of little pieces

that are interacting with each other in

fairly

simple straightforward ways um other

people

want to have big giant functions and big

giant

tables and big giant uh

objects so that they can see everything

all at one glance

and i think this is a legit difference

in thinking styles

um this is one where i'm not going to

say my way is just

strictly speaking better

uh so in this

in this uh goal of reducing coupling

over time

if you can't get rid of it putting all

the

as we would say on the farm manure in

one pile

is better than having it spread all over

the place

that is this moment of creating cohesion

where you're saying

well we have all this code scattered all

over the place that does

i don't know authorization let's put it

all in one place

and it won't be any easier to change in

that one place

except that at least we know where to go

to look so that's this moment of

creating cohesion which tends to reduce

coupling

you can't always know that you're doing

it but at least

it gives you a path forward so there's

the original definitions of coupling and

cohesion

coupling is if i change this i have to

change that

with respect to a particular change and

cohesion

says if i change one of these things

then all of my siblings have to change

too which is a way of reducing the scope

of coupling

now i am the sort of person who

generates lots of ideas

and i've been thinking out about a bunch

of stuff lately

some of which ties together and some of

which i'm not going to be able to even

come up with a plausible story for how

it goes together but here's a

here's an observation that i made the

other day

um writing this tidy first book

so there's a loop that goes

somebody has an idea for how the

behavior

of a system needs to change and they

change the behavior

and that gives them more ideas for how

to change the behavior of the system

and so this is your user

sees your systems like this that behave

like this yesterday it behaves like this

today

we're hoping that that's a happy change

sometimes it is but as

a developer or a designer

you know that there's another loop

that's going on underneath the surface

you know the story about the swan at the

swan

up above it's all beautiful and majestic

and it just glides smoothly along

if you look under the water there's

these feet that are paddling and poop

coming out

so software development is like the swan

except the graceful and beautiful above

the surface part

thank you very much so the other thing

that's going on is

you you can't just change the behavior

you also have to

change the structure of the system too

and how the system is structured

effects profoundly affects whether or

not you can make the behavior changes

that you want

because of coupling exactly because of

coupling you say well

i could add this database but then i'd

have to go change these 20 places so i'm

going to take all those 20

places and i'm going to put them in one

object

and now it's easy for me to change the

database that's a kind of structural

change

that you can do before you make a

behavior change and that's exactly this

tidy first moment

that i'm writing about where you say

okay

yes i want the behavior system to change

like this but

first i'm going to change the structure

um i came up with the slogan

uh let's see i just i shortened it this

morning over breakfast

make change easy then make easy change

there you go that's your next t-shirt

idea

um and this is as programmers

we can be pretty massive massac yeah

masochistic sometimes like

the pain of programming is a badge of

honor

where oh this is going to be really hard

it might not work at all

and we think that's a good moment i go

good

i get to now use my wizard-like powers

as a programmer

well maybe that's the moment that we're

really screwing up

maybe that's a moment where we say well

making this change would really be

really hard

what would the system have to look like

in order for this change to be easy

i want to make the change easy then make

the easy change

well then you're just well actually

making the change easy can be hard

too so you have to reply recursively

because i am a computer scientist

i did take those three years in college

of computer science

where it's kind of like a zipper you say

well

if the system was like this then this

change would be easy but to get the

system like this

is going to be hard but if the system

was like this then making that change

would be easy and if the system

zip zip zip and then you can make the

easy change

but that means that you're spending your

brain power

on making the next change easy not on

making the next change

and that can be uh that's a hard moment

uh like the

the people observing these behavior

changes

this is an artist's rendition of an

eyeball very interested eyeball

whoops what go

oh jesus now what if

anybody no connection

does anybody have any idea how to get

rid of this

yeah this thing here that isn't moving

all right all right what is the

collective salary of this room right now

i don't even all right

no not last cast the

all right there

can't even my operate my own damn

computer

well it's not really my computer apple

keeps doing things to it

um where was i

so from from the uh the outside observer

who just wants

the new report to be printed or the new

interactive

video thing to pop up when you don't

want it

uh that's where all the pressure

is i want to see the change of the

behavior

but as professionals we understand

that the structure matters to making the

next behavior change and even making

this behavior change and sometimes

it's important to do a little more now

so that we can continue making the kind

of changes that we want to make

i'm going to as i said i had to skip

some topics

oh

this is so frustrating

here's a experiment to try and then i'll

get to my i'll

conclude the experiment to try is to

carefully separate behavior changes and

structure changes

um like put them in different pr's

oftentimes you're programming away you

say oh and i need to rename this

oh and i need to add an if statement

here oh and i need to extract the helper

don't do that go back

and either do the do those in one order

or the other where you make the

structural changes the name

changes introducing new sub elements

make those changes that's one pr

finished done shouldn't change the

behavior of the system at all

and then make you the behavior change or

do the hacky behavior change first

and then do a second pr to do the

cleanup

to make those structural changes the

reason

i think underlying reason for separating

behavior changes and structure changes

like this

is that behavior changes in general are

irreversible that is if we s

augusto if we send out a wrong tax form

we can't take it back so you have to be

very

careful about irreversible decisions but

you don't have to be so careful about

reversible decisions and all structure

changes are reversible

if we extract out a helper we can just

inline it

right that's that's not a big deal you

don't need to apply the same level of

rigor

to reversible changes as you do to

irreversible changes

by separating structure and behavior

changes

give yourself a chance to apply

different standards

to what are very different sets of

decisions

the structure changes you can undo

easily the behavior changes

not so much so there's an experiment to

try

when you go back now here's the message

that i thought i was going to come

with to you and this is a big surprise

to me

something that sparked my interest

in uh what i call a 3x model explore

expand extract

that i came up with to describe

uh how innovation happened on facebook

[Music]

and

it is the resurgence of waterfall-style

development

exactly how stupid is that

well it's not actually stupid stupid

smart people

trying to solve real problems in a way

that just doesn't work

and we know it doesn't work but that

doesn't stop them

now we could have an interesting

discussion about the

psychological motivations for doing

waterfall development when you know it's

not going to work

but the fact is if you go out there

in the wild you see people saying stuff

that's very waterfally

now i at one point said there are no big

changes they're only big feedback loops

and i believe that applies to waterfall

when you've specified one thing

it's just so tempting to go and specify

the next thing without getting feedback

on those first set of decisions

it doesn't work because one we can't

predict

and two the very act of making a change

in the world causes the world to change

which makes the next thing different

so the waterfall doesn't work it never

did

it still doesn't it you know this time

is different

it's not different and yet

there are people saying very waterfally

things

and we'd at least introduced shame to

the equation

20 years ago or be able to go well i

have this big spec

and they'd feel bad about it now now no

it's like i have a big speck

what do you have oh a bunch of test

cases

somehow the idea that feedback loops

just simply

have to be long has come back

into fashion so this is one of the

advantages of being an old person

is i get to look at these things come

back around and he's like

oh yeah i know how this one ends

might take five years for all y'all to

figure out how this one ends but at

least

i don't have to worry about it because i

know how where it's going

the ddd community is perfectly placed

to counteract that tendency

by insisting on feedback

you're the people who analyze

more carefully and more thoroughly than

other folks do

but when that moment comes when you've

made some decisions and you know that

they're

at risk you're also the people who are

perfectly positioned to say

time out i'm not sure about what we've

done

already i'm not comfortable adding

more layers and more layers on top of

this let's implement something

let's put it in front of people let's

see how they act

let's see how that changes the context

let's see what we learn

from that feedback loop before we start

making another

set of decisions based on

these risky assumptions this room

and your compatriots are perfectly

positioned to

to tee that up and say nope we're not

going to continue

however good it feels however

much progress we feel like we're making

however many

insights we gain into the domain by

thinking really hard about it

that's a thing we need to do that but we

need to spread that

over time and here's how we're going to

do that

now i'm not quite sure how your

community spreads your techniques

over time in that way so i'm going to

leave that as an exercise to the

listeners but what i can say is

in addressing our collective moment of

insanity going back to

very very long feedback cycles

you have an opportunity a unique

opportunity

to address that sooner and quicker than

the people like me who are talking to

mostly to folks who are writing code and

writing tests and think that they

shouldn't write tests because they don't

have not a design software and

it's a long story but that's what i

would that's what i wanted to come to

you to say

is the water falls back it's stopped

apologizing

and it needs to be killed with fire

thank you very much