A Daily Practice of Empirical Software Design - Kent Beck - DDD Europe 2023

Domain-Driven Design Europe 2023
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
The economic rationale for software design is increased revenue & decreased cost. The relationship rationale for software design is to encourage trust through a steady delivery of value. The humane rationale for software design is to care for & encourage the growth of the geeks working on the software &, by extension, care for & encourage the growth of those affected by geeky decisions.
A short list of principles & observations serves to explain why satisfying all these rationales is difficult--coupling & cohesion, time value versus optionality, power laws. The same list suggests a way forward for software designers in a complicated, conflicted, uncertain, & deeply human world--large changes in small, safe steps.
We'll start with a 10x/day situation--you need to change some messy code. Do you tidy first? (Spoiler: likely yes, only as much as you need for now.)
About Kent Beck:
Kent consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Gusto, he is the author of many Addison-Wesley titles.

[@MarcusHammarberg]

Goodness from start to end. Such much to unpack here. Also - looks and talks a bit like John Malkovich - never noticed that before. That's a movie I wanna see - Being Kent Beck.

[@marcusradell7544]

One of the best talks I've ever listened to. The description of coupling and cohesion was Correct, Understandable, and Terse. Sometimes you can get all three 😄

[@kdiggity1]

Another brilliant talk from the legend.

[@gabrielemastrapasqua2939]

What a wonderful talk! Thanks Kent Beck! 🤩

[@TSD0416]

Thank you so much for uploading this talk. Excellent talk and thank you Mr Beck for sharing your experience, knowledge and insights with us Geeks in the world ❤🙏

[@brettdelia]

Great talk. Looking forward to the books. Loved the Powell's Book store shoutout!!

[@stephendgreen1502]

Best talk on software design I’ve seen

[@maverickmusic101]

Great talk, thanks

[@jimmyhirr5773]

The definition of "cohesion" here sounds just like Meilir Page-Jones's definition of "connascence." It's even characterized by strength, locality, and degree.

[@maximandreev593]

I liked the highlight that coupling/cohesion are respective to changes.

[@PhilipNee]

learned immensely.

[@aaronzhong]

Great talk, looking forward to the books! Separating the behavioural and structural changes feels like another way to look at TDD in the green and refactor cycles, or possibly even an iteration on the TDD flow with red - refactor (tidying first) - green - refactor?

[@FlaviusAspra]

41:00 "lumpers and splitters". Ask the devs which type they are and their yoe and if they used to be the other type and at how many yoe they changed. Then you're able to tell what common developer wisdom is.

[@jimmyhirr5773]

"Why are we still storing our code in files/directories?" Because Code Bubbles (Andrew Bragdon's project, not the unrelated startup) never caught on.

[@bonsairobo]

"Why are we still putting source code in files?" "Compared to what?"

[@encapsulatio]

He is one of the lucky influential people in software development domain who programmed in Smalltalk in his early career and of course he's going to make inside jokes that only other people who know what Smalltalk could do 30-40 years ago is still space age technology compared to keeping source code as text files like we still do today.

[@bonsairobo]

@@encapsulatio Are you referring to "image-based persistence"?

[@antesmolcic4354]

Easily watched at 1.25 speed :)

[@AAZinvicto]

For me it was 1.5

[@mlntdrv]

I am a bit of a genius myself as well.

[@lars4953]

"Im glad I made it" lol...

[@bartholomewtott3812]

I can't find this definition of coupling in structured design

[@davidglaubman6341]

A beautiful talk. I have one question (nitpick?). Since coupling is defined wrt a delta, and cohesion is defined as an entity A whose components are coupled, it seems to me no easy thing to determine if A is cohesive since the space of possible changes is so large. Maybe this doesn’t matter in practice since the idea is to reduce cost of coupling by moving coupled components closer together (increasing cohesion)? Also you ask why we keep code in files - what is better alternative?

[@KentLBeck]

Cohesion should also be defined wrt a particular change (or set of changes). Better than files of text in hierarchical directories would be a native AST store. We had this in Smalltalk way back when and it was glorious.

[@bartholomewtott3812]

I can't find Kent's definition of coupling and cohesion in structured design.

[@prathykt]

He should be writing the 3rd book first because that is what helps in identifying what changes come in.

[@igo_rs]

Boring. Lifecoaching becomes a valid excuse when there is no engineering.