Clean Code - Uncle Bob / Lesson 3

[Music] how many biological parents do you have a to that's right it's the number two and then there's no exception to that rule everyone has two biological parents there are some bizarre situations where there could be some other thing going on but in general it's - how many biological grandparents do you have huh four ish it's four for how many biological great-grandparents do you have that litter eight yeah cuz you know cousins you know the number of ancestors you have as you go back by generation ought to be the number of powers of two it ought to be a power of two but because of this cousin factor it begins to shrink so as you go back further and further in time the number of ancestors in your family tree gets much smaller than a power of two so if you go back ten generations for example you could have as many as 1024 ancestors but you very probably have far less than that probably less than a hundred most people tend to live in the same area their families tend to live in the same area you lose track of cousins after a generation or two so who knows right there could be all kinds of cross lines so let's assume that a generation is oh I don't know twenty ten power of ten now am I thinking this let's go back ten generations ten generations is too years roughly and so that would be what 1819 and you have a thousand possible possible ancestors but you don't really have that many let's go back 400 years 20 generations you have a million possible ancestors 2 to the 20th is roughly roughly a million you have a million possible ancestors the year is 1619 probably though you don't have a million back there at all you probably have a very small number maybe a few hundred let's go back another 10 generations and now the year is 1419 Columbus has not yet sailed you have a billion possible ancestors 2 to the 30th but there were probably not a billion people on the planet go back another 10 generations the year is now 12 19 the Magna Carta was signed four years ago you have a trillion possible ancestors there have never been a trillion human beings ever including all the dead ones so clearly this does not go by powers of two it somehow starts out as powers of two and then it starts to curve inwards and then the question is does it go parallel or does it really curve inwards as you go back in time to the number of ancestors begin to decrease and the answer to that is yes a number of ancestors begin to decrease and this becomes clear when you realize that if you go back far enough in time there may be a lot of people alive back then but they'll their lines have a positive probability of dying out and so you can go back far enough so that only one line has not died out the line that you happen to be on and that's a reasonable proof to suggest that if you go back far enough in time you will find one man and one woman who is the source of your genetic material all of your ancestors go back down to - so our ancestors grow by a powers of two and then they shrink and they head back in and they go right back down to two and that's interesting now we could do that analysis for everybody in the room and we'd have to go back further in time but if we did we would find that for everyone in the room there was a single common mother and father two people somewhere in the distant past who were the source of the genetic information for everyone in the room these two people did not know each other they probably didn't live within a hundred years of each other or even 100 miles of each other but it's a mathematical certainty that they existed we could do this analysis for the entire planet and find the mother and father of everyone alive today the Adam and Eve of everyone alive today and this is just a mathematical certainty these people existed is there anything we can learn about them well it turns out there is because most of our genes are mixed all up together with all kinds of well you know meiosis and is a is a messy process we cut the genes up and we mix them together there's no good way to tease apart the genetic pathway to the original Adam and Eve but there is a strand of DNA within your bodies that you only get from your mother and it's called the mitochondrial DNA not midi-chlorians mitochondria and the mitochondrial DNA lives in a little organelle within your cells called the mitochondria it's not in your nucleus it's in the mitochondria and egg cells have mitochondria and sperm cells don't so you only get this strand of DNA from your mother who got it from her mother who got it from her mother all the way back to the mitochondrial Eve now we know roughly the rate at which these molecules mutate so we could compare each other's mitochondrial DNA and if if two individuals had tentacle mitochondrial DNA then you would expect that they had a common mother very recently but if there were one or two differences you would expect that oh maybe there's a mitochondrial mother Oh sometimes slightly further in the past and if there were many differences well then you'd expect that to be very far in the past and we can do the analysis on the entire human race we do it statistically of course and we calculate the number of differences we know the rate of mutation and we wind up with a fascinating number mitochondrial Eve lived about a hundred and fifty thousand years ago that's not a very long time when you think about it a hundred and fifty thousand years ago now it happened to be in an interesting time geologically it was during the warm period before the last glaciation so mitochondrial Eve lived in a pretty good time we know where she lived she lived in the east of Africa we know that because that's where the most mitochondrial diversity is we know the paths the migrations that her children took we can see cohorts moving just in the in the genetic information itself we can see cohorts moving north and to the west into Europe and a completely different cohort moving to the north and to the east into Asia and a completely different cohort walking around the Pacific Rim around India and down into Indonesia all of those things we can see we can see a cohort crossing over the Barings bering straits at fourteen thousand years ago entering north america and getting to the tip of south america within a thousand years all of that stuff we can see men in the room you have a strand of DNA that only comes from your father it's Y chromosome Y chromosome does not mix during meiosis it's a pure strand of Y that comes from your father who got it from his father who got it from his father so the exact same analysis can be done on the y chromosome and we find that the Y chromosome Adam lived 70 thousand years ago at the height of the last glaciation in the east of Africa and we can trace the migrations of his sons can't see anything about the daughters but we can see the son and we can see how they migrated around the planet and the migration patterns are eerily similar but oddly different from Eve's patterns anyway it's a fantastic amount of information we can get out of just the molecules within our body and it leads to fascinating counterintuitive results which of course is not what we're supposed to be talking about what are we supposed to be talking about well this particular talk that I'm going to do is on professionalism this is one of my favorite talks I do it all the time because in this talk I get to pretend who I should plug in the screen it's there it's there I get to pretend that I am your new CTO you do not want me to be your new CTO I would not be a good one I'm not a great administrator I hate the whole process of administrating things I hate all the politics I would much rather bury my brain in code and be on stage I like being on stage and I like writing code it's a very strange personality defective mine in any case you don't want me to be your new CTO but if I were your new CTO I would have expectations of you and I'm going to define those expectations for you over the next hour or so when you hear these expectations you will hear them with two ears one ear will be the ear of the programmer the other ear will be the ear of everyone else in the world the programming ear is going to hear insanity the everybody else in the world ear is going to hear perfect sense why is this important well I made the case a little earlier today about why we need Essex and why need why we need a moral standard why we need a professional so this is to talk about what those standards might be what that profession what we might profess within our profession but before we do that we should talk about one other thing I mentioned earlier about how many computers were in the room how many programmers are there in the world 16 million good number where'd you get that number no no no no no you read it oh yeah 16 million hmm I don't know if it's 16 million maybe it is I I rather think it's larger but of course it depends on whether you count the VBA programmers the number I like to use is a hundred million could there be a hundred million programmers in the world today is that possible okay well that's what ten to the eight ten to the eighth programmers in the world how many programmers were there in 1946 one Alan Turing first guy to write a program to execute on an electronic computer was Alan Turing and that was 73 years ago so we went from 1 to 100 million in 73 years now what kind of growth curve is that is it linear isn't that linear it's exponential it's an exponential curve yeah this one right goes like that and if it's an exponential curve then it has a doubling rate because every exponential curve could be an exponent of 2 so we're gonna say ok it's a doubling ray well how many doublings does it take to get from one to a hundred million it's not too hard to calculate 2 to the 20th is a million 2 to the seventh is about a hundred so right around 2 to the 20 okay well so there's twenty seven doublings between 1946 and now whoa okay what's the distance between the doubling how much time between doublings 73 divided by 26 is to an something 2.9 2.8 does the number of programmers in the world double every two point eight years is that possible now hang on that first decade they probably doubled a lot faster than that because you know in 1946 Alan Turing was the first programmer but the next day there were 10 and a few days after that there were 30 right but the doubling rate probably slowed down about 10 years later so we might guess that the doubling rate of programmers in the world is something on the order of 5 years and there is actually a substantial amount of data to suggest that the doubling rate of programmers in the world is roughly every 5 years the number of programmers in the world doubles every 5 years that's unbelievable that's a crazy rate of increase and it has deep implications and one of those implications is that half the programmers in the world have less than five years experience and as long as we are doubling at a rate like this half the programmers in the world will have less than five years experience we won't be able to escape from that which leaves our industry in a state of perpetual inexperience a lot of people look around the programmers and say well they're all young yes that's a young person's game old people shouldn't be bothered with it you know where'd all the old people go we're all still here there just weren't very many of us back then it's not like all the old people disappeared or anything like that it's just that you know hordes and hordes of 20 year olds have been pouring into this field for the last 30 years and all the old people are going whoa how do young kids around here wish they'd get off my grass who has been gathering the body of knowledge in our field where is the experience gone the experience clusters in a relatively small number of programmers who have been doing this for a few decades but there aren't very many programmers who have been doing this for a few decades half the programmers in the world have been doing it for five years or less a quarter of the programmers in the world have been doing it for more than ten years that's the level of inexperience that we all face how do we get the information out that's been learned by all these old dudes how do we get that out to all the young people who are pouring in and if you believe they already know how to write code write a book I can write a book can you write I can write a book you can write a book we can oh you think they're gonna read it who teaches them professors professors in college professors and college are 10 years behind most professors in college who teach programming never wrote a line of code for pay in their life right at the the the universities are turning out people who are woefully unprepared for what they face once they get a job did anybody get the shock of reality when you got your first job and thought see this isn't like school how do we how do we instill within programmers the knowledge and the desire to profess a set of ethics and one way might be to have expectations so here are the expectations I have of your new CTO my first expectation is we will not ship now I know the programmer ear is already going that's insane we have to ship there's no way around it I mean what do you want us to do actually make the code work but the rest of the world the other ear is going well yeah I mean what you mean you're shipping this is the first thing we have to overcome and I realized that the the phrase is a little bit over the top but I want you to think about what has happened over the last 30 years do you realize that people now regularly download betas you understand what a beta test is right a beta test is when you carefully select a few trusted users and you tell those users all hell's gonna break loose when you use this code please be careful but it would really help us if you used this code to feed us back and now of course we just set people download them yep it's beta tough tough bananas boys and you know what we're never uploading anything but bait is it's going to be betas from now on this is the attitude of people who are uploading code into the Internet do you believe that code must have bugs very careful as you know you do right you know you believe coat must have bugs I mean when I write code it has bugs all code must have bugs I don't want my expectation I should say my expectation is that when you release code you know it works you know it works you don't guess that it works has anybody done the guessing game I think it works the deadlines coming man should we ship it oh you know I think it works I mean it worked yesterday on my laptop when you release code I expect that you will know that it works you will know to the best of your ability to know that may not be a perfect ability but I want it to be the best of your ability to know that it works when you release code I expect that it will be as high a quality code as you can attain within the period of time necessary I don't want you to just release things that you think sort of work I don't want you to release things that you think are ok enough it should be clean it should be tested it should be well organized it should be good solid coat and you know who expects that everybody expects that except you everybody does if I buy a product from someone I expect a high quality product if I am using a service from someone I expect a high quality service I don't expect them to come to me and say well you know there's always bugs I buy a car from someone right I expect that car to work I expected to have been tested and put through the wringer I expect that car to work and I'm going to complain bitterly if even the smallest thing doesn't work that's what all of our customers expect of us I expect that we will always be ready now what does this mean who's doing agile look at the hands go up you're all doing agile wanna bet you have an iteration size the sprint length what's the length of your sprint two weeks who's got two weeks anybody got longer who's got longer than two three three who's got longer than three who's got shorter than two anybody got one one week one week what do you got back there one week one week that's good the the programmers for the mercury space capsule the avionics software in the mercury space capsule had an iteration length of one day they wrote their unit test in the morning and they made them pass in the afternoon we are now satisfied with an iteration length of two weeks okay two weeks is probably not too bad I like one week better a lot can go wrong in two weeks so I like one week but okay two weeks fine that means that I want to be ready to deploy every two weeks now what do I mean by ready to deploy I mean that from your point of view from the technical point of view the system is ready to deploy it may not have enough features to deploy that is a business decision from a technical point of view it is ready to deploy every two weeks okay you can log out but you can't log in but log out works all right and you're ready to deploy it if the business comes to you and says hey can we deploy you say yeah can't login you can log out but deploy it cuz it'll work that's what I want and what does it mean to be ready to deploy it means that all the testing is done but all the documentation is done everything for the current said if teachers is done every two weeks now if you're doing agile you already know this because what is supposed to be done at the end of the sprint what should the states of the system be at the end of every sprint if you are doing agile if you've been studying scrum shippable deployable deliverable that's exactly right so if you are not deployable at the end of every sprint you are not doing agile you're doing something else not agile and agile you are ready to deploy at the end of every sprint and that is not too big an expectation I should be able to expect that I should be able to expect that you will work for two weeks and at the end of that two weeks we'll have a system that is ready to deploy even if it is still under featured that's fine does anybody here have a burn in period a stabilization period you know what this is right you've got the release already the code is all ready for the release QA says it works and everything and then and then you put it in a system and you turn that system on but it's not connected to anybody and then you watch it for a long time that's not smoking looks like it's still working you know like maybe if we let it work like this for another month we could ship it this is irresponsible time executed here does not tell you that the system is stable you should already know that the system is stable you should have the suite of tests that shows you that the system is stable that little burn in period is a false hope oh if it runs for a month then it's probably okay no it's not you should be ready every two weeks or one week that'd be even better I expect stable productivity what does that mean it means that the longer the project goes the slower you don't get you do not slow down as the system gets older you are able to produce features at the same rate at the beginning of the project and at the end of the project and in the middle of the project the feature production rate does not slow down you are stable II productive this is a reasonable thing to expect the rest of the world expects this adding new features to a system should not cause you to slow down the reason we slow down and I told you this before is because we make a mess and as the mess builds we get slower and slower and slower I don't expect the mess I don't expect that we are going to get slower and slower and slower as we move forward how slow can you get yeah I see right answer pretty damn slow pretty damn so I worked for a company once and the the minimum estimate for anything didn't matter what it was was six months James the name of one menu item six months and there was a good reason for this and the reason was that the programmers had been so badly burned by missing estimates and the cost of misting estimates to them personally and professionally was so high that they simply refused any estimate lower than six months they simply wouldn't do it also the system was so badly coupled that changing the name of a menu item was liable to break something somewhere because we actually had other systems that read our menus yeah talk about a mass and so anything that happened in that system was six months I expect inexpensive adaptability it should be cheap and easy to make changes to the system inexpensive adaptability it should not be expensive for me to make a change or rather I should say that the this the cost of the change should be proportional to the scope of the change if it's a big change it's probably gonna cost a lot if it's a small change it shouldn't cost very much that's what I expect I do not expect you to say when I come up with a small change from a customer I do not expect you to say Oh God that destroys our entire architecture it ruins our whole design you don't understand we're gonna have to reroute all the communication in the system to do this I don't expect to hear that why software is a compound word first word is soft second word is where the word where means product the word soft means soft changeable software means changeable product software was invented so that we could easily change the behavior of our machines had we not wanted to change the behavior of our machines we would have stayed with hardware but we did not stay with hardware we wanted our machines to be easily changeable and so we invented software to the extent that your software is hard to change you have simply reinvented hardware you have thwarted the very reason that software exists if someone comes to me and says that change to the requirements the warts our architecture my response is well your architecture socks because you have thwarted the very reason that we invented software in the first place your software must be changeable I expect inexpensive adaptability how do you get changeable software well you keep it damn clean for one thing number two you better have a really good suite of tests because when you change one part the code I don't expect another part to break I want you to be able to change the code at will I expect well that is an expectation that's coming continuous improvement I expect continuous improvement of what of the system of the code the code should be getting better with time not worse the code should not be degrading or rotting the code should be getting better with time because we are human beings that's what human beings do human beings improve situations with time they don't degrade situations with time human beings are not bacteria we don't Rock things we improve things but most of the time our code rots I don't expect that I expect the code to get better with time every day the code gets a little bit better I expect the design of the systems to get better with time the architecture of the systems to get better with time because I expect that there's a group of highly competent people working inside that system improving it continuously that is a reasonable expectation for me to have and it is the expectation that the entire world has of us now I expect fearless competence fearless competence you're staring at your screen there's code on your screen somebody else wrote it as you bring this code up on your screen the blood drains from your face oh god this code is a mess and you think briefly in your mind the thought strays in maybe maybe I should clean it and the next thought overrides immediately I'm not touching it because you know if you touch it you will break it and if you break it it becomes yours so you walk away I'm not gonna be the one to clean this code somebody else can clean this code but and me I submit to you that if that is your reaction to the code the only thing that can happen to that code is that it must rot because you will change it from time to time but you will change it in a way to minimize your personal risk not to improve the overall structure of the software you will change it to minimize your personal risk and that will always be the wrong choice for the system the system will simply rot and no one will ever clean it it will get worse and worse with time and the whole team will slow down by a factor of 10 or 20 over a period of two years I don't expect that I expect fearless competence I don't expect the fear I don't want you to be afraid of the code are you afraid to touch the code are you afraid to improve the code do you have that little echo in your ear saying Ava's ain't broke don't fix it I expect you to improve the code all the time fearless competence how do you get fearless confidence tasts what if I had a button a little button I could push on my keyboard and some lights would blink and science-fiction sounds would come out of my laptop for a few minutes and then a little green light would light up and that green light told me that the system worked and I believed it given that little light and I believed it I look at my screen it's a mess I think ah I should clean it and my next thought is I think I'll change the name of that variable push the button oh yeah green good that function is a little too big I think I'll split it in half push the button Oh green good didn't break it okay I'm gonna move this function over into that class over there push the button whoo red put it back push the button green good oh oh oh I see put it over here push the button green if you had that button and if you believed it you could clean the code you would clean the code it would be trivial to clean the code you wouldn't have to spend much time at it either you could just say well you know don't spend five minutes cleaning up to go a little bit push the button a few times do a little bit of clean up do check it in just a little better than it was before and everybody could do the same little dance check it in just a little bit better than before we call this the Boy Scout rule check it in a little bit better than you found it always check the code in a little better than you checked it out if you had the tests and if you believe if you react in fear you become fearfully incompetent if you conquer the fear with tests you become fearlessly competent you keep control over the code I want you to think about how wildly irresponsible it is to fear what you have created to respond to it to react to it to allow it to master you instead of you mastering it and would it be that hard to make that suite of tests yes do I want you to write unit tests for code that other people have written first I want you to write unit tests for code you have written conquer that problem first hey now is that the easy part really that's who's doing that right now testing every single line of code that they write okay that's not a lot of people so this is not the easy part let's get that one done first then we can talk about the code that other people write and do I want you to write unit tests for that go to yeah of course I do I want you write tests for every bit of the code I want the code to be test I want you to have that button I've got that button the systems I write I've got that button I can push that button and I have absolute control over that code I can do anything to that code I want and I can do it fearlessly because I know from step to step to step I haven't broken anything when you experience that for the first time it will knock your socks off you mean I can change this thing it is a remarkable experience there will be more to say about that in the next hour but yes go ahead yes yes yes broken unit tests that are absolutely useless yes is that a question so the question was he has seen over the years that unit tests can be created so coupled to the system that if you change anything in the system a whole bunch of tests break this is called the fragile test problem the fragile test problem is a problem that is experienced by people who are new to test-driven development if you have only been doing test-driven development for a year or two you are very likely to come across the fragile test problem and the reason that you come across it is you have not yet realized that tests are part of the system and have to be designed as part of the system they cannot simply be thrown in there as a bunch of tests tests are an integral part of the system that must be designed with all the same rules that we've always used to design any part of the system so let me explain what I mean by that if there is a part of the system over here and another part over here they're not tests they're just parts of the system and you make a change over here and it breaks a thousand things over here what can you say about the design of that system it's talks yeah that's a terrible design that by the definition of bad design the definition of bad design is when you make a change in one place and the thousand things break in another well okay now turn these into tests you make a change over there and a thousand tests break you got a bad design how do you fix that well you design the test you isolate the tests from the system you decouple the tests from the system you build api's for the tests you use all the same techniques that you use for normal system design for the tests and you wind up with tests that don't break that way I'm not gonna go further that although you did say one very scary thing to me and I will harp on that for a moment does anybody measuring code coverage oh yeah good okay do you have a target number what's the target number 85 so it's okay if 15 percent of this code doesn't work right there is no target number that makes any sense other than a hundred percent right you can't go arrest you know we've got 80 percent code coverage so I guess 20 percent doesn't work then the only target that makes any sense at all is a hundred percent and you cannot achieve it you can't get to a hundred percent so you have to look at it as an asymptotic goal a goal that you keep on tribe it's like losing weight you know I'll keep on trying sometimes I lose a pound or two okay so it's very much like that you keep on working to whittle that code coverage down but you'll never get to 100% number two don't let managers see that number ever it is not a management metric managers don't understand what the metric means code coverage doesn't mean anything outside of the context of the team the team understands what it means the team knows that those are the lines of code that are executed and the team understands how many asserts are in the tests if you make this a management metric and by God help you help you if you actually put it in the build and fail the build if you don't meet the number then what happens is the programmers in order to make the number will start pulling asserts out of the tests and the tests will become meaningless and the code coverage number will shoot to the sky you can get a hundred percent that way don't do that this is not a management metric it's a team metric it's a personal introspection metric you get the coverage of the code that you are working on the team gets the coverage of the code they are working on they look at it privately they assess what it means in the context of the system and they act accordingly but they don't publish the number and it is not a goal sorry that was a rant expect that we will not dump on QA all right let me get that off the screen this is disgusting I expect that we will not dump on QA QA is not the the group that finds bugs did I miss one well same quality okay good they're all part of the same thing I expect they that we will not dump on QA QA is not the tool we are going to use to find bugs in our system QA should find nothing do you have a QA group you use QA who's uses QA Oh some people do good why do we have QA departments what would motivate a company to invest in a separate group whose job it is to detect whether or not the developers had done their jobs apparently the developers hadn't done their jobs but why would a company create a QA group well because they got burned so badly by not having one why did they why did they get burned badly because the developers didn't do their jobs it's the developers jobs to make sure the system works QA can serve a useful function that's fine but the function they should serve is not at the back end of the process waiting for the load to be delivered the function of QA is to specify how the system ought to behave QA people have been telling us this for decades nobody pays any attention to him we don't want a bunch of people at the back end writing you know running tests executing tests like they are computers we don't want a bunch of people back there you know has anybody looked at a manual test plan you know what kind of hell that is and her X Y Z Z Y into the password field click okay did the login called the screen come up check here yes this is your job for the rest of your life right that's awful and by the way what happens to QA do you think the beast actually delivers the load on time you think that developers give the QA folks enough time to actually test the system hell no do you think the date changes just because QA doesn't have enough time to run all their tests no so who's under the most pressure in this environment what team is under the most stress the most pressure to get something done and it's always QA they're always sitting at the end they're all always under hellish pressure and in that context we're going to guarantee quality it's absurd QA doesn't belong at the end of the process Qi belongs at the beginning of the process developers guarantee quality of their code not QA QA should find nothing the QA tests should find nothing you run you release a system you hand it off to QA you expect them to find nothing if they find something your reaction ought to be how the hell did that get loose how the hell did that bug get through there we got to do something to prevent that again because we never want QA to find QA should wonder why the heck they're stuck at the end of the process because they want to go to the beginning of the process anyway and how do you do that well I expect automation test automation every test in the system should be automated every QA test should be automated if a computer can do it a computer should do it if the manual test if you've got a batch of manual tests I expect them to be automated because look what programmers that's what we do we automate stuff and so I'd be very expensive to automate the test know it's expensive to run the test you see this picture here the hands there are the hands of the QA manager the years 2008 he's holding out to me the table of contents for his manual test plan he has 80,000 manual tests that he must run once every six months he sends it off to an army of testers in India it costs him a million dollars every six months to run that suite of QA tests he's holding it out to me because the year is 2008 the financial crisis has become his boss has just come back from the CFO's office telling him that his budget is being cut by 50% he's holding this out to me asking me which half these tests he shouldn't run I told him you can cut the document this way or that way you're not going to know if half of your system works this is the inevitable result of manual testing manual testing always leads to losing the tests you will leave or loot either lose them this way the big big glaring way when some accountant finally says this is too damned expensive or you will lose them in a much more insidious way and the insidious way is this the QA group doesn't have enough time to finish their tests because the developers are late and the QA group now has to figure out which tests to run I'm seeing myself on that screen I did not expect to see myself on that screen oh geez it's following me the queue the QA Grove now I'm distracted the QA group has to decide which tests to run to cover the changes so they look at the changes that were made and then they make a guess about which tests they ought to run they do an impact analysis and they discard the rest of the tests if the programmers knew they were doing that the programmers would tap them on the shoulder and say um you really need to run all the tests because you know we changed virtually every line of code in the system one way or another if you're doing manual tests you will lose those tests there is a disease that infects in software development organizations and it's very interesting to how do you know if QA is doing a good job if you're managing the QA team how do you know that they're doing a good job what metric could you use you could what oh yeah get complaints from the end-users yes yes use defects the number of defects that got through QA or regression testing time how long does it take to do the regression test well if it's manual it's going to take a hell of a long time QA should be finding defects if QA finds a lot of defects they must be doing a good job this puts a positive value on defects someone now values defects q I would like to have defects because they can now announce that they found them and that's good for them now who else wants defects there's an old rule in programming right I can meet any schedule you set for me if the code doesn't have to work name the day I'll be there now that's interesting right because that implies that if there are enough defects I can meet the scheduled programmers who are under schedule pressure love defects especially if they can shuttle them off to QA and QA loves the defects is then they can say hey look at the defects we found no one has to say a word but the economy of defects gets set up both sides love the defects and nobody knows this trading is going on I expect as your new CTO that we will cover for each other we will behave like a team how does a team behave you got a team of people there moving a ball down the field and there as there as they're passing the ball back and forth and moving it down the field one of the players trips and falls down no flag is piled on the play the play continues what do the other players do they cover the hole they change their field position they keep the ball moving down the field that's how a team behaves teams cover for each other when a player goes down if you are in a software team you should be able to cover for each other if somebody goes down and people go down on software teams all the time if somebody goes down somebody else needs to be able to step into that role how do you make sure that someone can cover for you it is your responsibility if you go down someone should be able to cover for you how do you ensure that someone can cover for you well it'd be really helpful if you sat them down at your terminal at your at your screen and walked them through what you were doing you could do this by pairing I might get back to pairing didn't I you can do this by parry this is the reason that we want to see people pairing we want people pairing so that we know they can cover for each other it's your responsibility to make sure that someone can cover for you so you will invite people to pair with you so that they can learn what your source files look like and where you keep them what your make scripts are and how you deal with git and all that stuff so that if you go down somebody can step in and say yeah ok I can take over has anybody worked in a team where bob was the database guy and bob went down and nothing happened on the database for a month oh I don't know anything about the database that's Bob this is this is stupid right we're a bunch of programmers we know how to do this stuff we just need to cover for each other we need to behave like a team teams cover for each other I expect that I expect that if I've got a team of 15 people and I decide I need to divide that team in half and take seven people that way and eight people that way the eight people remaining will still be able to operate because they know enough about the whole system to continue behaving like a team that means they're going to have to share an awful lot of knowledge probably by pairing so let's talk about this pairing thing for a bit people get very scared of pair programming because they think they don't want to sit next to some guy forever and I'd be awful and what if he's got bad breath or something it's always good idea to keep some you know breath mints in your pocket just in case but okay I don't want you to pair 100% of the time I don't I don't need one in a pair 50% of the time I want you to pair enough so that you can cover for each other and that you can review each other's code how long should you pair an hour just a half an hour hour something like that pair for you know a few times a week a pair for an hour hour and a half something like that maybe a couple of times a week just enough so that you have enough knowledge to cover for each other and that you're reviewing each other's code I also think you ought to pair with lots of multiple people so people should pair on the work that you're doing and you should pair on the work that other people are doing on a relatively regular basis and this should all be very informal I don't want some manager putting a big chart on the wall saying today Bob will pair with Bill that's a stupid thing to do just everybody ought to be able to strum time to time say you know what I'd like to I'd like to work with you for half an hour an hour and we can kind of learn what each other are doing that's a wise thing for a team to do and if you did that you could probably eliminate most of the code reviews you do because pairing is a much better way to review code so keep that in mind I expect honest estimates what is the most honest estimate you can tell me three little words I don't know it is the most honest estimate you've got because you don't know right anybody who pretends they know how long something's going to take is lying and by the way if you make an estimate of a date you are lying if someone comes to you and says can you get this done by Tuesday and you say yes you are lying you don't know that you can get it done by Tuesday unless you're absolutely certain for some reason maybe it's a one-line change and Tuesday is eight weeks away that would be an interesting week wouldn't it hmm so how do we deal with this because the answer I don't know is the right answer but it doesn't contain enough information managers are going to need something better than that because they have to be able to manage you know managers have to manage things so what can we do well what we can do about this is we can define the shape of what we don't know we can put a boundary around what we don't know and to do that is actually very simple this is an old idea it goes way back to the 1950s it was called pert project evaluation in real time it was used on the Minuteman missile system was very successful old idea great idea and the estimation part works like this you don't give an estimate of one number you give an estimate of three numbers the first number is the best-case case someone says okay here's this task and you have to estimate it and you say well okay if everything goes right and I mean everything you know you right eat the right breakfast cereal every morning every day you go to work your coworkers are actually polite to you you vrat you watch the right TV shows at night you get solid eight hours of sleep every evening all that stuff right everything goes right it's gonna take me a week then the next number is the nominal case this is when things go the way they usually go okay if things go the way they usually go I'm gonna spend half my time in meetings and arguing with Mike workers and my wife and I are gonna get into a fight half the time and get won't be useful for coding for a few days and it's probably gonna take me three weeks and then the last number it's the worst case the worst case is everything short of nuclear war right everything goes wrong right there's there's production outages every day and they take you all day long to fix and your co-workers are rude and they're throwing spitballs at you and half of them are sick and you have to deal with all their crap anyway and you say okay if that happens it's gonna be eight weeks one week three weeks eight weeks that's a really honest answer it's probably right now no manager wants to hear that by the way I just management's a number give me a number no I can't I can give you three no no I want a number now I know I can give you three I can't give you one number I'd have to lie and I don't wanna lie I only give you three numbers and then because you're giving them three numbers the managers have to do something that well I hope they're used to doing they have to manage because the job of a managers to manage that kind of risk now of course they'd like to limit that risk as much as possible by making you absorb it but you must not absorb it if you don't know you can make it what's in hmm okay yes it's 3:15 good it's time for a break [Applause]

Channel: UnityCoin

Views: 283,675

Keywords: programming, software, clean code, polite code, shrunk code, programming language, computing, technology, society, ethics, human relations, uncle bob, robert cecil martin, edsger dijkstra, grady booch, future, rules, java, c#, c++, microsoft, functions, declarations, arguments, cycle, kotlin, InteliJ, methodology, agile, scrum, tdd, test driven development, programmer, responsibility, expectations, architecture, design, development, applications, app, structure, web, study, practice, optimization, productivity, purpose

Id: Qjywrq2gM8o

Length: 59min 41sec (3581 seconds)

Published: Wed Aug 14 2019