Is This Why You’re Bad At Programming?

i have strong opinions on how to do software development well i think that if you followed my advice you'd increase your chances of success the trouble is that some of this is just my personal opinion and that alone is not good enough to convince you or at least it shouldn't be we're all victims of our own experience we're all limited if that is all that we consider science and engineering allow us to learn from other people's experience but the way that we do that is based on evidence and cautious exploration of ideas i think that the most profound difference between an engineering approach and not is that in engineering we start off assuming that we're probably wrong just because we hold an opinion doesn't mean that it's right so how do we go beyond making decisions only based on opinion here's my exploration of seven common excuses that software developers make for doing a worse job [Music] hi i'm dave farley of continuous delivery welcome to my channel and if you haven't been here before please do hit subscribe and if you enjoy the content here today hit like as well i'd like to begin by thanking our sponsors harness equal experts octopus and spec flow they're helping us to develop our channel so please check their links in the description below if you'd like to learn how to adopt the engineering approach that i describe on this channel in your own work check out my training courses there's a link in the description to those below too the approach to software development that i generally recommend rules out some ideas and practices i think that's a good thing i don't believe that all ideas have equal merit if you believe the world is flat you're simply wrong i think that waterfall development is flatter thinking for software development it doesn't work and it tries to address only some of the problems in what are fairly naive ways while ignoring others this is opinionated it is my opinion but it's also backed by some evidence if you look at data for the success of software projects then waterfall projects fare badly in terms of efficiency quality and basic measures of success like did it deliver what people really wanted now waterfall proponents will argue that the data was probably collected wrongly and that the experiments were compromised in some way but let's take a slightly more pragmatic view are there any organizations that we think of as doing a great job of software development that claim that this is the result of practicing waterfall if i'm honest i can't think of any i picked waterfall as something of a straw man but how do we reject bad ideas although i think that most people if asked would say that waterfall is discredited and no longer thought of as a sensible approach my impression is that most organizations at least implicitly still think this way so we can't even get rid of an idea that is as discredited as waterfall there are lots of myths in our industry so how do we bust them i describe practices that sometimes challenge people's assumptions and experience the consequences of ideas like continuous integration continuous delivery and test driven development when followed to their conclusions are disruptive and challenging but they work better when i publish my thoughts on these ideas i sometimes get pushback from people which is fine but i try to approach things from a more scientific engineering approach rather than just saying it's good because i like it so what does it take to change my mind first if i recommend a practice here that means that i've always tried an alternative i certainly can't claim to have tried every alternative of course but i've always tried more than one so yes i have worked on projects that didn't have automated tests yes i worked on projects that didn't have version control continuous integration or any of the other practices that i talk about here and the reason that i talk about these things and not the others is because in my experience these things work better as far as i can i try to determine the these things work better pass based on two things in addition to only my personal experience is there evidence to back up the claims and can i make a reasoned explanation of why this idea might work better than alternatives the evidence part is easier than it used to be these days we can look at the results from the state of devops report a detailed survey of the performance of thousands of software projects based on 45 000 surveys over several years now you may choose to argue with the approach but if we are to be scientific or even just rational in our thinking then you need to present a better alternative the state of devops is based on measures of stability and throughput stability measures the quality of the work that we produce and throughput measures the efficiency with which we are able to produce work of that quality want to propose an alternative good then do the work and show your evidence for why your measures are better or your approach gets better scores in stability and throughput you can't simply reject the findings based on personal experience or hunches well you can but don't expect to be taken seriously if you do my second qualifying criteria is can i form an explanation this is part of taking a scientific approach to reasoning about these things too it's valuable to have a model for why the things work the way that we think that they do then we can evaluate our ideas against our model and we can test our model based on the evidence and experience that we gather by trying it out for example i think that continuous integration is better than feature branching that isn't based on my personal preference i've tried most ways of branching that you've probably ever thought of and maybe a few that you haven't thought of unless you're prone to nightmares but there is data that backs up my claim and i think that i can refute arguments for feature branching based on a reasoned rational model for how information changes when we have copies in two or more places so let's try and apply this kind of thinking to some of the commonest pushbacks that i get about what ways of working better here are seven common pushbacks that i see all of the time the first is you can't do serious work without feature branching let's start here my views on continuous integration and feature branching are probably amongst the most contentious that i talk about to summarize i say you can't do both continuous integration and feature branching unless your feature branch lasts for less than a day so try to put your personal preference on hold just for a moment whatever it might be continuous integration is about continuously integrating our changes together what does continuous mean well in the context of continuous integration the experts and the definition of continuous integration say we should be merging them together at least once per day so once per day is the bare minimum to qualify for continuous integration what does integration mean it means checking to see if our changes work together that means everyone's changes so it isn't continuous integration if you only pull your changes from master to your feature branch even if everyone else is doing the same because the changes you're really interested in are hidden away on your teammates feature branches you're not integrating with those so what does the data say well the state of devops data says that you create worse software more slowly when you feature branch or at least when your feature branches last for longer than a day so to change my mind on this you'll need evidence that thousands of teams build better software faster this way and or a reasoned argument on why two copies of data that are changing independently of one another get easier to merge together the longer you leave them to diverge neither of these is going to be very likely because continuous integration is the more definitive approach at the at this level of explanation explanations based on but i like it better don't really cut it i'm afraid it's not a fashion show the next in my list my manager says i don't have time to do x whatever x's there's always the chance that any one of us ends up working for a dom manager but while i concede that this can be a nasty systemic problem sometimes i think that this is always the wrong response trying to offload this responsibility to other people there's a choice at work here how much of the detail of our work do we choose to expose discuss in the context of planning to put this another way where is the boundary between the stuff that we are responsible for as developers and the stuff that is somebody else's job there has to be a boundary obviously we're not going to say i spent this much time typing the letter e this week how much time should i spend typing ease next week this is ridiculous so why do we do the same thing for writing tests refactoring or spending time on good design rather than hacking out some crap code we software developers are complicit in this decision the root of this problem is and this is only my theory probably comes from two different sources some of us really don't like testing very much and don't really want to do the hard work of doing a good job of design and refactoring so we pass the book onto somebody else some manager knowing that the poor ones will say feature feature feature the other course is that we don't really believe that testing and good design make us faster if you're here then i assume you'd like to do a good job and so don't fall into the first category so i'll concentrate on the second quality pays the evidence is in there is no trade-off between speed and quality as counter-intuitive as that may seem if your team wants to deliver features more quickly the only way to do that is to build higher quality software the state of devops report says that teams that practice continuous delivery get high scores in both stability and throughput they spend 44 percent more time on new features than teams that don't that is you're at least 44 more productive if you practice these kinds of techniques that is a commercial advantage right there so it really is pretty simple if your manager says feature feature feature the correct response is right boss we hear you we need to spend more time testing refactoring and improving our designs because the data says that's how you deliver features fastest now i know that this can feel counter-intuitive but that's just your instincts and your biological drive to jump to conclusions kicking in science is how we overcome those biological limitations why is it that this is true what's our model well it's actually pretty simple you trade off a bit of extra work now for much less work later on by focusing on the quality of your work now by doing that you dramatically reduce the amount of work spent later dealing with buggy or low quality code it's not somebody else's responsibility to give us permission to do a good job next on my list writing tests is a waste of time and my code is good so i don't need tests okay at the moment when you write the code also writing test is clearly more typing but if you really measure your work by the number of characters that you type then you're doing it wrong that aside if you write code you are presumably going to test it somehow even if that test is just running it to see if it works if you don't even do that you should stop right now because your code doesn't work and you're a danger to others so now the only question isn't test or not test but what's the most efficient and effective way to test and while running it manually or watching it executing your debugger have a place if they're the only way that you're testing your code you're wasting a lot of your time it's a much more efficient work process when your development is guided by automated tests making a small change and running the test gives immediate feedback in seconds rather than starting up the app injecting some test data and then pouring over the results thinking why not did it do that in addition to all of that the impact on the quality of our code of designing for testability is profound and goes much deeper than just having a test to show that it works testable code is more modular more cohesive and has better separation of concerns it also hides information and is more loosely coupled these are all properties of high quality code and they're the these properties are give us the ability to manage the complexity in our code as i describe in my new book next in my list you can't do code review with continuous integration yes you can of course you can pull requests aren't the only way to do code reviews pull requests were invented for open source projects where you want to gatekeep changes from people you don't know and don't trust to change the code safely if your team works like that you have bigger problems than code review here's a thought experiment imagine for a moment two teams in one team all of the members are confident and competent enough to commit changes safely they take care to do work quality work in the other team some members can't be trusted to work safely so must be monitored closely now think for a moment in idealistic terms which would you be the nicer team to work on which the more effective i think that most people would prefer the first team so what would it take to grow a team that worked like that well gatekeeping people's commits is slow and inefficient and more than that it doesn't really teach people how to do a better job my preferred way is to address these problems with pair programming pair programming gives us a better code review than code review alone it doesn't slow the process down so there are no stores of code sitting around waiting for review somewhere if the pair agree on the change they commit it if they don't agree they don't commit it and they discuss the problem and fix it and then commit it this has a more subtle and ultimately more important effect though as well as getting the code review we're also involving even junior members of the team in the process of thinking about changes more carefully at the point when they make them not some time later this is a much better way to learn how to take responsibility for their changes and the importance of doing high quality work there is good data on the effectiveness of pair programming too i've put some links in the description below next okay these ideas may work for simple web apps but not for my system well i'm afraid that that's simply ignorant speaking google has 25 000 developers working in a single shared repository they run millions of tests every day store billions of lines of code in that one big repository and deliver feedback on each commit to each developer in minutes i was part of a team that built one of the world's highest performance financial exchanges the whole enterprise system was built from day one and he still developed over a decade later running continuous integration test driven development and continuous delivery in the way that i describe on this channel we practice trunk based development on everything including solving some world-class difficult problems and we produce the highest quality code base in for a big system that i've ever seen the techniques that i describe are also used by volvo trucks tesla spacex on us military programs the global telecoms giant ericsson are rolling out their entire 5g network using continuous delivery aaa games banking finance and newspaper systems are built this way so there really is no kind of software for which this doesn't seem to apply and it's not just for simple web apps last in my list we've always done it this way and it works for us well that's nice but wouldn't you like to be able to do better if we never question our approach and practices then we'll never improve the ideas that i describe here are backed by experience in companies of all kinds all over the world working on all kinds of problems they're backed by data that shows that this way of working is more efficient and produces better results and they're backed by good explanations that can describe why they work but i guarantee that in each of these organizations that i've talked about they're also always looking for ways to do better that's part of this approach too so if you really want to challenge these ideas come up with some better ones i and many other people will be delighted to adopt them but they do have to be at least as good as what we already can do and to be honest what we can already do is a lot better than many maybe even most organizations and teams except as normal i think that what we are talking about here is the difference between real engineering and not between applying a scientifically rational approach to solving practical problems in software and not and part of that approach is always having an open mind that there may be a better way but not simply adopting every new idea because it feels nice or because somebody famous likes it thank you very much for watching [Music] you

Channel: Continuous Delivery

Views: 82,173

Keywords: software developer advice, software engineering advice, bad software, bad software design, bad programming habits, bad programmers, junior developer, junior software developer advice, software developer mistakes, continuous delivery, devops, Dave Farley, software development, software engineering, programming

Id: pAX8GAsRaYk

Length: 20min 9sec (1209 seconds)

Published: Wed Nov 03 2021