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

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.

Find plenty more from Dave on his @ModernSoftwareEngineeringYT channel.

Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.

ABSTRACT
What are the bad programming habits that make bad software? What are the common excuses that programmers make for writing software that is worse than it needs to be? What are the common software developer mistakes that people make?

In this episode, Dave Farley describes the common excuses that developers make for doing a worse job and describes his software engineering approach to how we can debunk mythology and lazy thinking in software. So if you are a junior software developer or any software developer who strives to do a great job, take a look and see if you have any of these bad habits, and listen to Dave’s advice on how best to avoid them, or maybe show where Dave is wrong.

CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

RECOMMENDED BOOKS & LINKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:

#GOTOxDaveFarley #TDD #Programming #SoftwareArchitecture #CD #ContinuousIntegration #Testing #UnitTesting #UnitTest #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery #Accelerate #Complexity #ProgrammingTutorial

DAVE'S LINKS

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[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

[nickdolan]

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 :-)

[Tony-dprl]

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.

[deang]

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.

[manojtutika]

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. :/

[kyussx]

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 ?

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

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

[Constantialismus]

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

[wjrasmussen]

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

[justwanderin]

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

[filipetome]

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.

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

[Walruz]

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?