Is This Why You’re Bad At Programming? • Dave Farley • GOTO 2023

[@pnwsnewton]

7 Excuses 1. You can't do serious work without feature branching 7:13 2. My manager says I don't have time to do 'x' 9:22 3 & 4 . Writing tests is a waste of time, My code is good so I don't need tests 12:50 5. You can't do code review with continuous integration 14:38 6. These ideas may work for simple web apps but not for my system 16:55 7. We've always done it this way and it works for us 18:22

[@Wineblood]

I haven't watched the video yet, but are points 3 and/or 4 basically "tests good therefore TDD good"?

[@Tony-dp1rl]

Is there a repo containing applications or libraries Dave wrote that make use of the techniques he talks about, so we can check them out? Nothing speaks to this sort of thing more than actual code.

[@nickdolan8068]

30 Years ago, I worked in a 10 man Financial Team writing C code for Banks, our "trunk" and CI was a set of floppy disks passed around at the end of each day for everyone to commit to the floppy and then after you committed / pulled you build the code to make sure it compiled .... seems we've not moved far or are returning to old ways :-)

[@manojtutika7461]

I'm a CTO with 9 people team, I would have shared this video with my team if it wasn't for the dumb click bait title. :/

[@deang5622]

Waterfall is generally not a good methodology but I have seen instances where it does work and one of those was a $4.3 billion project. You have to spend a lot of time in the requirements definition phase.

[@atlasstic]

No company claim to do waterfall because waterfall is not a framework or methodology. It is a consequence of working in a certain way and while not everyone has the same phases, everyone that work with expert areas and not generalists do use a phase cycle way of working. This is true in all companies that have project based organizations and all companies that have ideation that is based on scientific research rather than throwing shit on the wall and see what sticks :) The problem with phase based work that people call waterfall was the length of the cycles and the isolation of each phase. If you change that then phase cycles are no better or worse than any other ways of working. In fact most companies that I have worked with that claim to be Agile are doing phase based cycles with Scrum rituals and roles.

[@deang5622]

I disagree. Waterfall is a methodology with defined phases. However, what tends to happen is companies recognise the shortcomings of it and they change it and one way they change it is by having a number of cycles with a delivery at the end of each cycle. Yes, it's starting to look more agile like, but it is not agile.

[@atlasstic]

@@deang5622 Would you mind pointing me to where you find that methodology described? Isolation and "throwing things over the wall" type of handovers are bad in any methodology or framework. Scrum suffer from self-isolation and detachment when used the wrong way for example. If you shorten down a phase based way of working to the same length as a Scrum sprint, or PI plan, and collaborate instead of isolate each phase... there is not much differentiating it from Agile frameworks.

[@kyuss0x1]

What if the feature I am implementing will take more than a day to complete should I push my crappy code into master branch just to pretend we do continuous integration ?

[@Mr7Shane]

less click bait thanks

[@Constantialismus]

There is a typo at the beginning of the video: "proffesional software developer"

[@filipetome6738]

I'm sure this video is filled with sensible common place advice. There was a point in my life where Dave Farley helped me understand some key concepts in building software. But this click bait title playing to insecurity is just obscene. There's no excuse for such a buzzfeed-esque approach to content for professionals. I won't be giving mr Farley my attention again.

[@donaldstrubler3870]

Understood. Consider though, that moderate thinkers understand the theme itself and appreciate the "nature" of the contents he's presenting. If one sucked at programming they wouldn't be able to fully appreciate the wisdom in this video. Therefore the title is paradoxical either way. Excellent people don't want to suck. Not that they don't want to suck entirely, rather they become excellent by not sucking in specific life domains successively. I don't want to suck on documentation, and I'll gladly watch a "why your documentation sucks" video. It's the contemporary language, sadly.

[@deang5622]

Up to you whether you give him your attention again, but I see that is naive and immature behaviour, because you don't know if you will benefit from future videos he produces. You might. So you are in fact doing yourself a disservice. If all or the majority of his previous videos were rubbish then you might be justified in not watching future videos because you've observed a pattern and you can use that pattern to make a prediction about future videos - which is that they too will be rubbish. You have clearly benefited from watching videos produced by him in the past. And that benefit is obtained at an individual video level. So you can't identify now today whether you will benefit from future videos from him because they haven't been produced yet. Your freedom to do what you want, but you are supposed to be an educated professional and so you should be intelligent enough to exercise good judgment. But I don't see it.

[@RFalhar]

"It is always a chance that any one of us will end up working for a dumb manager." I would say that it is rarer to work for a non-dumb manager. In the few teams I worked in, only small few were what I would consider non-dumb.

[@justwanderin847]

Your banking systems and ATM's were most likely developed decades ago and used waterfall. Agile is just mini-waterfalls.

[@wjrasmussen666]

where do I get the dev ops report. I googled but there are a number of them but I think it isn't the one you want. Only 77 pages.

[@YefoAkira]

"pull requests were invented for Open Source projects" ... yeah!!!!!

[@ben.aka.bigben]

Good contents with a bad title

[@arcfide]

Dave, I love your take on CI, and I've seen it applied very successfully. However, I've seen teams complain that some members of the team are so productive that the system changes so rapidly that other members of the team can't possibly read all of the commit logs coming in and keep track of all the changes. They want to halt development in order to discuss the changes that have occurred, claiming they can't integrate their changes since "by the time I read the commit logs and get up-to-date on all of the things happening in trunk, it's changed again!" Do you have any thoughts on this? What do you do when you're working with a rapidly evolving system and some people feel that CI is impossible because the pace of changes makes it impossible for them to integrate any changes themselves? This is assuming that automated testing and even pair programming is already established.

[@stephanweinberger]

That sounds more like group of lone warriors than a team. Limiting branch lifetime to one day (point 1 on the list) and pair programming (point 5) could be approaches to solve (or at least mitigate) this.

[@arcfide]

@@stephanweinberger Both of these practices were already mostly happening on the teams I'm thinking of. The problem was still that even with rotating pairs that kept all of the pair programmers rotated around, some pairs would always outperform some of the others so much that the other pairs would complain of not being able to keep up. I suppose one approach would have been to limit integrations to no *more* than once per day, which sometimes was done, but that still resulted in the problem of some teams producing so many changes that it took "too long" for the other teams to be able to grok the changes to begin their own integration. If the pacing of changes were reduced as much as I think some people wanted, the project never would have had a chance of getting done at all. I guess the core problem I'm wondering about is how you deal with situations in which the disparity in productivity is so high in some teams that some of the members, even with pair programming, don't feel that they can keep up, without turning the entire project into a slow crawl for the sake of the least productive members of a team? Is this just a matter of needing to rebalance teams to not have this? Or, is there some way to deal with this disparity and eventually eliminate it?

[@Walruz1000]

What is wrong with shortlived feature branches? I can't really see a huge difference between only using trunk and using features that live for a day or two? I also find the PR mechanism good for building ephemeral environments which are then automatically torn down when the branch merges to trunk. I thought this was a nice approach and we still deploy changes in day to production and integrate code with trunk regularly. If I regularly rebase my feature branch against trunk am I not in theory working on a branch that is being continously integrated?