Why Your Software Team Can't Scale • Dave Farley • GOTO 2023

[@danieldossantospereira835]

I would really like a video on the Platform team. Thanks for the video 👏

[@fburton8]

Hi, Dave, do you have a link to the Disruptor that you mentioned in your very interesting talk? I found something on the Weblog, but the Google code page redirected to a github page that doesn't exist. Thanks.

[@towel9245]

Useful overview, I hope I can use the knowledge one day.

[@gJonii]

This video helped me finally verbalize what's been bothering me about this channel for a while. The topics are discussed in a way that Dave literally can't be (proven) wrong. There's never enough concrete real world connection to disprove anything, and here even book recommendation was based on "I read it, didn't learn anything but smiled and was nodding because I agreed with everything". It's super easy to be right if you make claims only so deep into abstract, disconnected from reality, that you might as well be arguing about how elves should organize in the Middle Earth

[@Jedimaster36091]

I don’t think it’s fair to expect a step-by-step guide on how to, or a detailed overview of the book, especially for free. I am actually amazed that we get so much from this channel. Personally I found this particular video informative and useful and could use it as a opening discussion in my organization.

[@gJonii]

@@Jedimaster36091 What one can expect however is discussion to be grounded on some concrete real world thing. Without grounding, you're left arguing about the number of angels you can fit on a head of a pin. And you get people nodding, not because they are learning something, but because they agree on the angel count.

[@ContinuousDelivery]

@@gJonii The ideas that I talk about on my channel are ALWAYS based on practical, real-world experience, unless I explicitly say that they are not. To my mind none of this is theoretical, it is VERY well trodden ground. As far as I can see, the reason why all software doesn't work this way, is people resisting trying new ways of doing things. Sure it is difficult to adopt some of these ideas, when other people are against them, and that is a problem. But I would argue that the reason that you find it difficult to argue with the points I make, is because this approach is logical, rational and hangs together as a structured, effective approach. For example, you can't really argue that Continuous Integration is the BEST way to get regular, frequent, clarity on where you stand in terms of producing working software. You can't really argue with that, because it is a fact, not an opinion. This is also backed up by evidence, from the State of DevOps reports that demonstrates the impact on efficiency and commercial success of effective CI. So now all we are talking about is "how to achieve it", and that naturally leads you to ideas like TDD and Pair Programming Continuous Delivery. These are all logically consistent. So the rational response, as far as I can see, is to either refute them, or adopt them. Deciding against is an irrational choice if it means you build "worse software slower", which the evidence says it does.

[@PaulSebastianM]

Is DevOps a platform team or should a stream aligned team know what doing DevOps means?

[@DannyEck]

Yes please re: ep dedicated to "platform team". Term is getting tossed about at work. Engineers lobbying for a formal unit subscribe to a different creed than the dev managers that would beg/borrow/steal resources in order to form one. I'd like to hear an informed opinion.

[@briancolfer415]

Trust and size may be relevant but communication patterns and size are probably more relevant.

[@wrjacqmein]

Love the Conway's law reference - en.wikipedia.org/wiki/Conway%27s_law

[@thorstenhirsch]

There are lots of them in the book, including the Reverse Conway Maneuver. ;-)