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

[@ruixue6955]

14:25 SOLID (in Clean Code book) 16:40 18:17 code demo (discussion on SRP) 18:54 the discerning observer (thinks about why) 20:27 how is that limitation changed 20:30 1st: we started to *collocating these people in the same team* 20:56 recently they even became the same person 21:15 *fullstack* 21:55 back in the day, ...! 22:34 *now the team get out of the field* 23:35 logical conclusion: 25:32 separation of concerns 26:10 Dijkstra: a concern is *holistic* , e.g. correct vs efficient 26:15 e.g. getting data and separating data (are what most people consider as separate concerns), this is not what Dijkstra said 26:34 Dijkstra: whether the program being correct is a different concern from whether it is efficient 27:29 28:32 let's actually separate concerns 28:37 *behavior* and *code structure* are separate concerns 29:07 *keep code together while it fits in your head* 29:39 when it doesn't fit in their head => move the code to "gather together things that change together" 30:19 *critiques on clean code* 30:32 when you have 300 people (300 classes) coding together, it makes sense 30:42 HTMX 32:28 OCP 38:06 scrum 44:12 alternative to Scrum

[@KelvinMeeks]

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

[@bbry323]

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

[@henrikholst7490]

The SCRUM critique landed well with me.

[@PaulSebastianM]

Love Dan North!

[@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".

[@edgeeffect]

SOLID may (or may not) be more guidelines than actual rules. But there's a lot of people in the industry (and many of them are conducting job interviews) who believe that SOLID is the very word of God himself... "and although I don't understand a single word of it, I expect you to obey, Obey, OBEY!"

[@topsiterings]

Lovely

[@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?

[@Tony-dp1rl]

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

[@edgeeffect]

Isn't that just fab... when enlightenment has reached such a stage when a Christian can quote The Life of Brain... and it's OK. :)

[@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.

[@daniel-terhorst-north]

Thanks for your feedback. I have applied SOLID principles over many years before I realised they were causing more harm than good. I have exploded some perfectly readable code into myriad tiny classes and interfaces, before realising what an awful mess I had made. I have read Clean Code and, as I say in the talk, it contains some of the worst code examples and advice I have come across, especially in the modern age. I have written software for over 30 years, in huge and tiny organisations, in heavily regulated environments, in programme teams of 100+ engineers and start-up teams of three. I have seen many, many codebases. Our opinions may vary, but please don't think for a moment that a) I have not lived the experience I am sharing, or that b) I am 'doing this for the clicks'. This is hard-won advice that I share again and again, and I tend to get gratitude and positive feedback from the teams and organisations I have worked with.

[@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

[@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".

[@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"