The Most Dangerous Phrase • Daniel Terhorst-North • GOTO 2023

This presentation was recorded at GOTO Copenhagen 2023. #GOTOcon #GOTOcph
gotocph.com
Daniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & Associates ‪@daniel-terhorst-north‬
RESOURCES
/ tastapod
/ danielterhorstnorth
github.com/tastapod
mastodon.social/@tastapod
dannorth.net/blog
ABSTRACT
Some advice is timeless; it ages like a fine wine. Each time you revisit it you discover a nuance, a new connection to something else. As you grow, the advice is waiting there to reveal another layer you had never considered.
Some advice is a product of its time; it ages like milk. It starts fresh, then it begins to smell, and eventually it rots and can even become harmful! It made sense in the context and constraints of its day, but things have changed and it is no longer relevant.
As Admiral Grace Hopper famously said: "The most dangerous phrase you can use is 'But we've always done it this way!'" Daniel believes this is why so many people have an almost religious zeal for SOLID, Scrum, and other antiquities.
In this session, Daniel argues from first principles why ideas like SOLID and Scrum made sense in their day, over a quarter century ago, and why they have been superseded and should now be considered harmful. For contrast, he suggests Continuous Delivery and lean product development are ageing like fine wines. If there is time, he will show how methods like SAFe have never been relevant and never will be, but can be appealing to a certain kind of manager. [...]
TIMECODES
00:00 Intro
01:10 Why do we do what we do?
05:02 The most dangerous phrase
06:32 Some ideas age well, others not
08:29 What does "aging well" mean?
12:45 Which limitation does the tech diminish?
14:23 When good advice turns bad: SOLID
16:15 Single responsibility principle
25:31 Separation of concerns
28:33 Let's actually separate concerns!
30:42 HTMX: A counterpoint
32:26 Open-closed principle
37:53 CUPID: The back story
38:06 Scrum
44:13 A modern alternative to Scrum
47:33 Why do we cling to obsolete tech?
49:17 You must think for yourselves!
49:55 Outro
Download slides and read the full abstract here:
gotocph.com/2023/sessions/2891
RECOMMENDED BOOKS
Eliyahu M. Goldratt • Beyond the Goal • amzn.to/3wDbAL1
Kent Beck, Fowler, John, William, Don & Gamma • Refactoring • amzn.to/3SFBYbN
Kent Beck & Cynthia Andres • Extreme Programming Explained • amzn.to/3KeL5P5
Jez Humble & Dave Farley • Continuous Delivery • amzn.to/3ocIHwd
Robert B Cialdini • Influence, New and Expanded • amzn.to/3tL8GxB
Aino Vonge Corry • Retrospective Antipatterns • amzn.to/3naFk84
Subramaniam & Hunt • Practices of an Agile Developer • amzn.to/2XjbWor
Derby, Larsen & Schwaber • Agile Retrospectives • amzn.to/3hB4eNk
Jeff Sutherland • Scrum: The Art of Doing Twice the Work in Half the Time • amzn.to/2X4GQAD
/ gotocon
/ goto-
/ goto_con
/ gotoconferences
#Change #Scrum #SOLID #AgileDevelopment #ContinuousDelivery #CICD #Lean #LeanDevelopment #GraceHopper #Transformation #VESSA #SAFe #SpotifyModel #DigitalTransformation #DanielTerhorstNorth #DanNorth
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info...

[@KelvinMeeks]

Always enjoy the thought-provoking ideas that Daniel brings to his talks.

[@Rcls01]

I always watch Dan's talks. There has been a lot of bashing of clean code lately. Two things I want to mention myself. When someone asks about SOLID, I always reply using a quote from Pirates of the Caribbean: "They are more guidelines than actual rules". The other thing is you can modularize your application either from a technical perspective, or a domain one. Clean code is more about breaking it through technical needs.

[@tesla6422]

A lot of software flame wars comes down to someone saying "here's some advice on managing complexity from my experience" and a group of people going "ah so this is the only right way and we should berate those who deviate from this".

[@henrikholst7490]

The SCRUM critique landed well with me.

[@PaulSebastianM]

Love Dan North!

[@tesla6422]

18:54 Conway strikes again: [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin E. Conway, How Do Committees Invent?

[@ashimov1970]

As always with Dan's talks they look and sound fascinating and refreshing, however I wonder how these innovative agile approaches fit into highly regulated environments

[@topsiterings]

Lovely

[@bbry323]

Separation on single responsibility is also to read the code better and leave room for different implementations (?) 🤔

[@sjohnsonaz]

I feel like he's attacking SOLID Principles for edginess. SOLID works. Clean Code works. In my experience, the people who struggle with these, are doing them wrong. Ironically, he's attacking the strongest parts of these ideas.

[@sandrodelacruz8125]

I agree with you. He also takes SRP and applies it to the RoR architecture which is not appropriate. In fact, Uncle Bob specifically critized a RoR project for doing this layer by type instead of making it clearer what the app was about. Also, maybe the reason SRP was introduced was because of differnt teams, but it REMAINS because its still useful to divide up your codebase. I know if i started to work withe a new codebase that followed SOLID principles, I would be grateful.

[@sjohnsonaz]

@@sandrodelacruz8125 I'd say SRP really shines with Domain Driven Design. Pulling business logic into code, rather than mixing it with SQL, allows it to be tested synchronously. SRP allow reduces Feature Envy. It keeps classes and functions small, and self contained. Anyone giving advice to the contrary hasn't worked on a large project, or had to maintain a project over the course of years. Hence, this lecture was for edginess and clicks.

[@Venthe]

I've been in multiple projects that did like Dan is suggesting - "subdomain per report" instead of soc. And each single time it was a tangled mess, so no thank you. What you would describe as "fitting in your head" in this example meant that programmers messed up in a different places, fixed things only in certain modules because the code was not split along the responsibility boundary. It took us two months to sort out system written in this way; while we removed several classes of errors and while we were finally able to move rendering to 3p vendor. Which was practically impossible with code structured in a way that you are describing. E: watched it till the end. While the premise is hard to disagree with - "don't do things because they were always done this way" - the rest is basically biased rubbish. I get that you don't like solid or scrum, but why are you comparing xp - a set of programming practices - to scrum, a set of team organisation practices? Why are you blaming people not understanding "forecasts" on scrum? You are also constantly talking about continuous delivery being on opposition to scrum; that is not the case. You can release/deploy at any time, sprint servers the role of team alignment and assumption verification checkpoint. If you do work that is disjointed, then you'll not get benefits from sprints. If you do team work, then sprints will work, especially considering that people are not capable of delivering features in a "minute".

[@Tony-dp1rl]

Nice video ... although I will say Open Closed Principal creates more problems than it ever solved.

[@pneptun]

there is some truth to what he's saying, BUT it's demonstrably incorrect too. if what he's saying were true, SCRUM would have never gotten big in the first place. it was _not_ the original thing we used. i was there when it was new - and it was, well, new 😀so the fact it got adopted (over time) disproves the theory that the industry clings to old ideas and never lets go. if the idea is strong the industry will adopt it. yes, there is inertia, but if there are compelling reasons for the switch it'll switch. same with "new languages" - i was there when C/C++ was all there was. and then the industry switched to java/C#. recently (or relatively recently) it switched to js and python. so. the reason why the industry hasn't switched to whatever you think is "better" - not just processes, this applies to programming languages, technologies, development methodologies, whatever, you name it - so the reason it hasn't been adopted most likely is "because the arguments aren't compelling enough (or possibly inertia, but probably not)".

[@pneptun]

also he asks "why do we do separation of concerns?" and answers "people!" -> that's the last answer anybody would give. the true answer is "bcs if you don't you'll end up with a very tightly coupled code". you may still get very tight coupling if you separate concerns, it's possible. but if you don't separate concerns it's certain. so again, and more generally, the answer is "because we tried doing it differently (i.e. not separating concerns) and it was worse"

[@scottolmstead6054]

Does every talk have to be bait? Its exhausting.