Clean Code - Uncle Bob / Lesson 6

[Music] you think those are LEDs there and they're probably LEDs they're pretty cold only these are a lot more efficient than incandescent lights how do LEDs work light emitting diodes how do they work how does the light come out so LEDs it's just a semiconductor right so you've got two pieces of silicon and one of the pieces of silicon is doped with some atoms that have an extra electron and the other the other half is doped with some atoms that have a missing electron and that means that there's extra electrons on one side and missing electrons and the other and the electrons jump across the boundary to try and balance it and then a charge builds up across that and that's how a diode works and then when you forward bias a diode when you pass current through a diode you get this effect where electrons fall into the holes on one side and there's an energy gap between the electrons on the holes and as they fall it shakes the electromagnetic field and the photon comes out and that's why light emitting diodes emit light what you may not know is that all diodes emit light they don't have to be light emitting diodes all diodes emit light because there's always a little energy gap between the electrons and the holes on the on each side when I was a boy I played a lot around a lot with electronics and electronic equipment is relatively expensive so I would try to buy my equipment from surplus stores and there were surplus stores that would sell old electronic components and I would buy a bag of a hundred dots not half the diodes wouldn't work so what I would have to do is get all hundred diodes and put them in a pile and then I would build myself a little circuit and the little circuit had a little place where I could put the diode on and the circuit was a simple circus battery and a light and two nails in a bowl to complete the circuit I'd put the diet across the nails light would light up if the diode was forward biased and it wouldn't light up if it was backward bias so I'd take the diet and I'd flip it over and I should see the light light up or the light not light up and then I could toss them into a two piles those that work and those that don't but every once in a while doing that I would get a die at a regular diode and I'd put it across the contacts and it would light up would glow orange and I thought well that's really weird I was like 18 years old but the reason that was happening is because the manufacturing of those diodes was not real real refined it wasn't very accurate so from time to time they would build a diode that just had an energy gap in at the loud life to come out I didn't know that but I thought it was pretty cool in those early days they didn't want the light to come out because that was a waste of energy and then somebody realized that it might be a really good idea to have the light come out so then they figured out ways of increasing the energy gap so that red light came out does anybody remember when red LEDs first came out right yeah that was cool right because all of a sudden we had these new ways to light up panels and stuff like that and we had red LEDs everywhere remember the very first digital watch this would have been 1975 1975 the very first digital watch the Motorola Pulsar and it was black like this but you could touch the button and a 7-segment red LED display would light up telling you the time and then of course it would go back to sleep just like my current watch does some things don't change it didn't take long for green LEDs to show up it was about 10 or 15 years when the green LEDs showed up and and the reason it took that long is that the researchers were trying to figure out what chemicals they could use in the diode that would stretch the energy gap high enough to emit green photons that was not an easy problem to solve but they eventually got green night to come out reliable reliably and what you've got here this is actually two LEDs ones red ones green and when you mix them together you get this nice orange color well what we started seeing then was all of these red green signs and they would go alternate between red green and orange because they could turn on both colors at the same time so you saw lots of displays in stores that had red letters and green letters and then they'd mix them and get orange that was very common it took a lot longer to get blue LEDs as the energy gap is really big and the research has struggled for a very long time to figure out what materials they could use and what chemicals they could use to get that energy gap to grow to agree to a blue photon but they eventually got blue photons and all of a sudden we had all three primary colors and we could make LED panels and LED displays and look at that thing you know my watch just got red green and blue LEDs on it my screen my iPads got red green and blue LEDs on it and these LEDs they're so efficient so you burn all those those lights up there have got to be thousand watt lights well there they might be LEDs no they're not I already said they're not I looked at them with the diffraction grating they're not LEDs so it's probably a thousand watt bulb in there how many watts would it take to burn a-- to light up an equivalent LED and the answer would be about 10 watts no no about 100 watts about 10 times these efficient and that's why i can walk over to these things and touch them and they're not very warm because they don't use a lot of power i have outfitted my house with nothing but LED light bulbs all the light bulbs in my house or LED light bulbs in it it makes me smile you know i turn on the lights and they're all leds and they go yeah it's really cool it's all quantum mechanics is lighting my house now yeah and my wife god's lover grew up in a household where the father always said turn off the lights and i now i tell her honey it doesn't there's no power being used here it doesn't cost it turn off the lights ah well what can we say huh so our last talk of the day that there's supposed to be two talks but I'm mixing them into one because why the heck not you know last talk of the day is all about agile we're gonna talk about agile maybe hmm yes okay that looks good are we alright yes we're good okay fine how many of you were doing agile uh-huh that's everybody virtually okay what kind of agile is it and I noticed by the way you know there were hands in the air but they were kind of going yeah so okay fine what kind of agile is it this is scrum or scrum butt or scrum fall or XP so you do an XP XP stream programming what's your iteration size I think I asked you that right two weeks everybody in in two weeks good good okay well so why do we do agile what is the reason what is agile what does it mean to be agile so before we can answer those questions we have to go some of the go through some of the external reasoning how do you manage a software project now I've put some answers on the board up there and I imagine some of you have experienced a few of these answers and those are the wrong slides so let me get the right slide up there it is now the first one up there probably everyone has experienced how do we manage the software project badly another very common approach is hope in prayer you know that this is the approach in use if you can see two parallel lines dug in the carpet by the managers desk as he prays to God hope this project actually works and one of the really common techniques is to dictate and motivate we dictate by telling everyone how bad it's going to be if we don't deliver this project and then we motivate everyone by hanging pictures of people climbing rocks and seagulls flying over the ocean now we'll get the project done now the reason that we need to have a way to manage software projects is that mismanagement has some severe costs so for example if you mismanaged a software project you will build the wrong product who's done this one work for six months deliver a product have the customer look at you and say what the hell is this good that's mismanagement the project has been mismanaged right the managers have failed to manage the project properly they delivered the wrong product another way is another symptom of mismanagement is to produce a product of inferior quality who's done this one you worked for six months and deliver a pile of crap okay well that's bad that is mismanagement the project has been mismanaged has anyone ever been late you know that always works that is mismanagement right a software system is if a software system is late it has been mismanaged it is a management problem not a development problem a management problem the last one may not apply here I don't know if you guys work stupid overtime hours like we do in the United States in the United States it is considered a badge of honor to have worked in 80-hour week it shows your dedication to the cause I don't know if you guys do that but it's certainly mismanagement issue if you are forced to get a software system working by working tons and tons of overtime there is a management problem now why is it so hard to manage software projects what is the fundamental cause of this and the answer to that has been known for a very long time and it's actually a very simple problem good fast cheap done pick any three you're not going to get the fourth this is called the iron cross of sort of project management all the project managers know it in the room any project you do can be good fast and cheap but it won't get done or it can be done cheap and fast but it won't be any good pick any three you want the fourth one you cannot get by the way this is just a fundamental law of any project you do you cannot take all those things and get them all so a good manager has to look look that square in the eye and decide how to adjust the knobs how good how fast how cheap how done and a good manager will do that by adjusting the knobs with lots of feedback to drive the project to the best possible outcome that outcome may not be what was originally targeted you start a project with all kinds of dreams and hopes by the time the project is over you may wind up in a very different place but at least it's a good outcome and that would be a successful project now if you're going to drive a project to a successful outcome to it the best possible outcome what you need is data you're a manager you got to know what the heck's happening in there what happens you ever had a manager walk into the team room and ask the team how's this project going what's the answer pretty good you think there's any data in that I think managers gotten any insight into how this projects really going and everybody on the team is sitting yeah yeah pretty good pretty good don't tell them anything so there's no data coming out of that we need to find a way to get data how do you get data well what kind of data do we need wouldn't this be great this is a chart on the wall and the chart shows how much got done every week and what does it say if there's just story points well what are those I don't know some number doesn't matter what if you believed it though now this team got 45 points done that first week and the week after that it was like 42 maybe in the week after that it was 50 points in the week after that it was 40 points and if you look at that kind of study it for ten seconds to say well you know this team is getting around 45 points a week done next week they'll probably get around 45 points done over the next ten weeks I think they'll probably get 450 points done this is really useful information if you're a manager because now if you're a manager you could start to predict things you can look ahead you could say hey this team is getting about this much done every week okay and then there's another piece of data that would be really useful that's a burn down chart burn down chart says there's 400 and by 500 isn't it about 500 points remaining until the next major deliverable the next release and every week we see that number go down a little bit you're kind of hoping it's going down by 45 points a week although maybe it is maybe it isn't but at least you can look at that chart and notice that the chart has a slope to it and that slope lets you project out and say oh this thing's gonna be done this Minmei now you don't know if that's good news or bad news the manager does right if you're supposed to deliver in June that's pretty good news if you're supposed to deliver in April that's really bad news but at least you know right at least you're a manager you know oh now what happened on February 17th we we wound up working for a week with more to do and you said scope changes certainly possible maybe there was a requirements change do the requirements change of course they changed it's a software remember first we want the requirements to change any software team that freezes the requirements is making a terrible mistake no requirements freezes ever we don't want the requirements to freeze we want the customers to change the requirements as soon as they know that the requirements need to change so okay maybe that's what happened there and we want to know it as soon as possible so we can put it on the chart and everybody gets reset what their expectations are but the other possible reason that that bars a little bit higher is that the developers looked at the project again and realized that their estimates had been wrong and so they rested which is perfectly acceptable because their estimates they're not promises and therefore we want to know as soon as the developers realize and you know our original estimates for ignite we're a little optimistic we want to know that as soon as possible so everybody understands what's happening with this project put these two charts on the wall anybody can walk into the room where those two charts are look at those charts for 10 seconds and say huh this team's getting about 45 points a week done I think they're gonna be done in May that's really powerful of course may not may might not be a great number you might might have wanted it done earlier than that well that tells you you're not going to get there this is Angela the reason we do agile is to get these two charts on the wall you got these two charts on the wall mmm some of you do the rest of you if you don't have those charts on the wall you are not producing the data that the managers need to know how screwed they are the purpose of agile is to destroy hope some people say you know we're doing agile so we can go fast agile does not make you go fast doesn't slow you down either it doesn't change a thing about how fast you go agile is just a way to produce data so that you know just how messed up things are and then you can manage we want to know as soon as possible how messed up we are so that we can manage because there's this thing that managers do it's called managing we want to be able to manage the project to a good outcome there's a question right here whoo-hoo I get to throw this thing again No no no no no okay ready yeah okay the first one I think the team is responsible for but the second one is a product owner or manager I mean the team doesn't know the team needs to be fed with all the stories done in my environment they don't know it yet it no don't wait for two months in the phones but not for five months so is it the team you sponsibility then so this is the the the second chart there is the burndown chart which tells us the the number of points until the next major deliverable okay right so that deliverable has been planned did you know that in agile you plan out about three or four months what you're looking at all the iterations and thinking well these torch stories in this iteration and those stories in that iteration and we kind of think maybe it'll take another five iterations for these stories all that planning is done by the way that planning is done virtually every iteration so every iteration we curate another like three or four months look ahead yeah where are we gonna be in three months all that stuff is very variable but we do that and does it mean that we're not going to introduce new requirements in the midst no we do you can see it right there new requirements came in a new stories got added into this into the schedule that's fine this is agile this is the purpose of agile purpose of agile is to get these two charts on the wall if you don't have these two charts on the wall you are not doing agile you're doing something else now the charts have to be on the wall could they be in somebody spreadsheet somewhere it's better to have them on the wall because then everybody can see them and everybody can know how screwed they are and that's a good thing so I'd like to see those charts on the wall what are those points before we talk about the points let's talk about projects what's the first thing you know about a project before the project had named before there are any requirements there's one piece of data you have about the project it's always the first thing you know yes thank you the date and that's for very good business reasons because there's a bunch of guys who sit in the room and they say man we got to have something by November don't know what it is but it's got to be by November because there's a trade show in November we've got to be at that tradeshow or there's a shareholders meeting in September in November we got to be at that at that shareholders meeting project gotta be done something's got to be done or and this is a good one we run out of money in November this is a good business reason and engineers the developers often scoff at this idea that the business people create these arbitrary deadlines and force them to meet arbitrary deadlines what you don't understand is that those deadlines are actually real and there's real consequences behind them so you cannot scoff at the business deadlines they are real business deadlines they have real reasons behind them yes there are sometimes managers who set false deadlines that's immoral but most do not most are setting real business deadlines there's real teeth now the date is frozen there's no point arguing about the date it's a hard business date the requirements are not the requirements are changing at first we don't even know what the requirements are later on we'll get an idea what the requirements are but they're going to change all the time and why are they going to change all the time well because the customers don't really know what they want and the more we talk about what they want a better idea they kind of get about what they want but they really don't know what they want until they see something execute that is not what they want and then they say oh no that's not what I wanted so we're going to have to get things out in front of customers very early so that they can tell us oh that's not what I wanted I know it's what I said I wanted but now that I see it that's not what I want at all we need to be able to that cycle very very fast this is the environment of software developers it is an environment where dates are fixed requirements are not and somehow we have to drive the project to a good outcome now this is an old problem it's been around ever since software's been around and there was a guy who wrote about it in 1970 his name was Winston Royce and what he said he wrote a very famous paper managing the development of large software systems and in that paper he said wouldn't it be great if you could break the project up into three major phases and in the first phase we would analyze all the requirements and we'd put a date on the end of that and when we when we got to that date and we had analyzed all the requirements we would know that we were 1/3 done and then we would design the implementation and we'd spend the time designing the implementation and we'd put a date on the end of that and when we got to that date and when the design was complete we would know that we were two-thirds done wouldn't that be great now Winston Royce wrote that in a paper a lot of people agreed with him to sit yeah that'd be great so here's the picture that appeared in Winston Royce's paper on the first page the first page of Winston roses paper in which he made this case wouldn't this be great and in fact the case he made was this is how it's usually done this is how software is usually done now notice the the flow of arrows down those blocks it looks like water rolling down rocks it's called the waterfall model what Winston Royce went on to say in his paper is that that doesn't work because as soon as you get to the testing phase you realize the design phase is all screwed up and as soon as you try and touch the design you realize that the requirements weren't properly analyzed and you've got to really go around that loop over and over again and actually the only way to really get anything done is just to do them all at the same time apparently no one read that paper because the picture that appears in the process documents of the time that companies and countries adopted is just that one they took the first page they assumed they knew what he was saying they copied it into their documents that said this is the way software has to be done this was 1970 now I was a young programmer in 1970 I'd been a programmer for a year or two a professional programmer for a year or two professional in quotes and I remember when the articles started appearing in the trade journals about this new idea of dividing the project up new analysis phase in a design phase and an implementation phase and I remember thinking oh good some way to get some resolution on how to build a software project I was thrilled by the idea I was a young man I was thrilled by this idea some way some way to get some hold on a software project a lot of other people felt the same way apparently and we started building software that way so now I'm going to take you to a meeting this is a meeting that would have occurred in the 1980s of the 1990s big boss calls us into a conference room says all right got a new project to do you're all off your old projects you're gonna be on this new project we don't have a name for it yet don't have any requirements got to be done in November first now how long will it take you to do the analysis we don't have any requirements yet wait no no you're professionals you've been through this before I don't need an exact number just a date to put it in the schedule keep in mind if it takes any more than two months we might as well not do this project two months good that's what I thought too now how long will it take you to do the design Hayley Evan analyzer now I know you're professionals you've been through this before keep in mind if it takes any more than two months we're not going to do the project what do you say two months good that leaves us two months for implementation thank you for coming to my meeting who's been to that meeting enough of you the rest of you count yourself lucky because this is the way software was scheduled in the 80s and the 90s and unfortunately well passed into the 2000s and many companies so now you leave the conference room you go back to your desk what are you doing we're analyzing well what's that something now the great thing about analysis is is that you can read books on analysis there's a load of books on analysis and you can get all those books in your read them and you'll find that they all say different things people do not agree on what analysis is the best definition of analysis is that it's what analysts do but that's what we're doing for two months we're gonna do that for two months so this is a good time in the project because you know you can spend your time day trading and talking to some customers and writing down some notes and figuring out requirements and playing little games about what if it did this and what if it did that and I'm due to do doing all this kind of flurry work and then suddenly it's July 1st and what's the status of this project we're done with analysis why it's July 1st we don't want to be late so we might as well be done this great thing about analysis is you never know when you're done there's no way to tell when you're done there's no closure criteria there's no definition so you might as well be done on July 1st because you certainly don't want to be late and you have a big celebration balloons and speeches as you pass through the phase gate into the design phase everybody's on time this projects on track this is the first big lie that the process tells you all right now what are we doing now we're doing design now we know what design is design is pretty well defined right we're gonna be breaking the requirements up into modules and we're going to be designing the interfaces of those modules and we'll be breaking the the organization up into teams and figuring out the manpower of those teams and how they're gonna communicate and how the modules will communicate and all this very interesting work during the design phase meanwhile of course the requirements are changing and we'd like to go back and reanalyze those requirements but we really don't have a lot of time here because there's only two months so we kind of hacked those new requirements into the design but that's okay because the design keeps coming out and we're drawing diagrams and breaking things up and doing really fancy work and then it's September 1st and we're done with the design because it's September 1st because design is one of those things that you cannot finish you don't know when you're done with design analysis and design are not boolean deliverables they do not have two States done and not done they are simply open so now we're done with the design what are we doing now another speech balloons and speeches happy day the project's still on track if only we could do it one more time if only we could just say we were done with implementation and I know many of you have tried but there is something about implementation that actually has to be done so now we start the implementation phase what are we doing in the implement phase implementation phase it's completely clear what we are doing in the implementation phase we're coding and we'd better be coding like mad banshees too because we've blown four months of this project so now we're down there writing code like crazy writing code meanwhile the requirements are changing and you'd like to kind of reanalyze them and redesign them but you don't really have time for that so you tack them into the into the code and meanwhile you kind of look at the code that's coming out and you compare it to all those design documents and you realize you were smoking some really heavy stuff when you did that design because the code coming out doesn't look anything like that but you have no time to deal with cuz you've got a code like crazy go go go sometime around October 15th some developer sticks his head up above the cubicle and says hey what's the date oh man you mean we got to deliver this in two weeks there's no way we're gonna deliver this in two weeks and somebody goes and tells the stakeholders and you think the stakeholders are pleased can you imagine the state imagine you can imagine the stakeholders reactions you've probably experienced the stakeholders reactions what do you mean you cannot deliver it's only two weeks before the deadline couldn't you have told us during the analysis phase couldn't you have told us then that you were gonna be late weren't you trying to figure out how long this was going to take once you're doing the estimates during the analysis phase what about the design phase couldn't you have told a syst during the design phase weren't you sizing the modules and doing manpower analysis why did you have to wait until two weeks before the deadline and they've got a point so now the project enters the death march phase and morale goes into the toilet and everybody's trying to get something done and nobody's happy and the executives are throwing their hands in the air and the customers are all upset nobody's happy and sometime in March you deliver some limping thing that sort of half does what the customers want everybody is upset about this you come out the back end of that and you guys Jesus I never want to go through that again next time we're gonna have to do it right we'll do more analysis and more design now I call this runaway process inflation right you take the thing that didn't work and you do a lot more of it so here's agile agile comes along and turns us on its heads this wait a minute here's an agile project that lower right-hand corner is a date let's say it's November first first thing you know about a project is the date that doesn't change what do we do well we take the project and to the best of our ability we cut it up into a bunch of sixth time boxes those vertical slices there are all fixed time boxes let's say they're two weeks long all right so we know what the end date is we know what today's date is we can calculate how many of these boxes we've got how many iterations or Sprint's we've got let me say all right well that's that's gonna be our project now what are we gonna do in that first sprint that first iteration first two weeks some people call this iteration zero and what we're doing there is we're gathering some requirements not all of them because we can't get them all but we'll talk talk to the customer a little bit this is when we're writing use cases or nowadays we call them user stories we're writing user stories use and I'll talk to you a little bit about user stories later but a user story is usually just a word or two on a card don't need much certainly don't want a lot of detail yet detail comes later so we just want to kind of have a reminder a little card that reminds us of what this feature is and the features should be relatively small then we'll talk to the customers and will write down cards and we'll write down stories and what will get our source code control system working and we'll fiddle around with some design and architecture ideas we'll go to white boards and draw diagrams and try and figure out what the gross architecture of the system is don't want too much detail yet because we haven't really written any code but we kind of want some idea of the shape of the system and the module breakdown and so on we're doing kind of traditional design and architecture and analysis work for one iteration and at the end of that iteration we've done that for maybe a week or two then we start real implementation now we might have actually done some real implement implementation that first sprint but very often you don't have the time to do that so okay in the second sprint we begin doing some real implementation what are we doing well we kind of make a guess about how much we can get done in that sprint so we say you know we can get feature one if it's your eighth and feature twelve done in that sprint okay so we start to work and we're coding coding and of course there's requirements are changing on us but those requirements are getting shuffled into this deck of cards that we're creating so that's okay we're writing code and writing code by the end of sprint to the first sprint we're actually coding did we finish everything we said we'd finish no we're programmers we never finished everything we said we'd finish how are you not snow we didn't do that we miss just wrongly estimated everything we only got a little bit done but okay now we know we got a little bit done we did get a little bit done now we know how much we can get done in one sprint and we write that down and we do a little math and a little bit of math says we're screwed oh yeah looks like we're gonna be done sometime in March that's not good news but you see those brackets there those are the error bars the statistical error bars now they don't hold out a lot of hope for us either but you know maybe the next sprint will go better so we start the next sprint when things do go better yeah the source code control system was working a little better at the architecture idea we had is actually working sort of we refine it a bit because we're always at the board refining the designer or finding the architecture diagrams on the board and diagrams on the walls and stuff like that we're always doing that kind of work we're also coding you know making more stuff work and by the time we get done with the next sprint we actually did a little bit more than we did in that in that first coding sprint maybe we'll do that a few more times and by the time we've got oh you know three or four sprints done we can do that math again and now there's no point in hoping we're just not going to make November it's not going to have now by the way this is early in the project it's only been about five sprints for Sprint's five Sprint's something like that maybe a month and a half gone by we already know nope sorry not gonna happen we're gonna have to manage this project somehow so what can we do how do you manage the project well there's a bunch of options remember the iron cross of project management right there's four things you can manipulate so let's take a look at those four things we could go to that top nob the schedule knob go to the stakeholders as a stakeholders do you mind if we don't deliver until March now they might not like that because they had a really good business reason why November was today so it's very possible the stakeholders will say what no we need this in November not March can't be marks gotta be November however I will say that if there is a time to change the schedule this is it because it's still early they may have made no promises yet they may have made no plans if they're going to a trade show in November they may not have purchased the booth space yet if they're going to a shareholders meeting in November they may have made no promises to the shareholders yet and if they're gonna run out of money in November well I got a little bit of time to get a bridge loan maybe so early is a good time to tell everybody you're gonna be late not tell you a story about this I once ran a group that delivered a product to telephone company executives it was a long project we were gonna be doing it for a long time and we began and we told him we gave him a date when we thought we'd be done we came back a few months later and we said and we're not gonna be done then it's we're gonna be six months later and this group of telephone company executives stood up and gave us a standing ovation for telling them that we would be late but giving them enough time to prepare you should not expect that but it didn't happen to us now maybe the schedule can't change okay schedule can't change well there's another knob there the staff knob everybody knows we can go twice as fast by doubling the staff what double a number of people we can get twice as much work done that works every time doesn't it of course it doesn't work because doubling the staff does not have the effect of doubling the throughput what really happens is that when you add new people to the project the old people slow down enormous ly the whole schedule begins to slip because the new people suck the life out of the old people and you kind of hope that after a month or two the new people get smart enough to start getting faster and even if that's true it's risky as hell and besides that if you add more people to the project it's gonna cost more money so maybe there's no budget for that so let's assume that we can't change staff now I have changed staff I have run a project and we realized early on in that project that there was no way we could make the deadline and the deadline was really important it had legal consequences to it and so because it was early enough I was able to add a few more people to the project and yes we slowed down for a while but yes we sped up and we were able to bring the deadlines in a little quicker does work if you can do it early enough it does work but it's risky it's expensive so let's assume that we can't change the staff okay there's that knob at the bottom the quality knob everyone knows you can go much faster by producing crap so you know what guys I know you want to write tests and everything but we're really under the gun so you have to scrap all that testing stuff you're doing it you're spending too much time in code reviews kill that because we just don't have time for that and I don't want anybody you know following any kind of process anymore cuz that just takes too much time just want you to code that's a really good way to make everything slow down like crazy I've already talked to you about how you go fast you go fast by going well this is a bit in your head it's a single bit one bit it's in your brain if I could find it in your brain I would flip it for you but you're going to have to flip it for yourself and this bit says to you the only way to go fast is to go well when you flip that bit in your head by hard experience usually you will realize that that knob has to be set as high as it can possibly set all the time quality is the only way to go fast so we're not going to touch that knob and that leaves one other knob to turn what you scope maybe just maybe some of those requirements that we were planning on didn't really need to be there by November maybe the customer could live without some of those requirements for a while so let's talk to the stakeholders about that and see if we can live without some of these requirements stakeholders we can't deliver all of this by November we can deliver some of it by November not all of it so you need to take some of those out no no I can't take any of it out we need it all by November well yeah but we can't give it to you all by November look here's our math I don't want to see the math I just learned it all by November yeah but no there's no way we're all by the way this argument can go on for a very long time and although the stakeholders have the moral authority and the pure righteousness the developers have the data and if you work in a rational organization I leave it up to you if you do the data must win so at some point in a rational organization the stakeholders will say all right I should have hired a bunch of different people but I'm stuck with you all right I guess we don't need that one second from the end you can get rid of that one you're gonna give it to me later all right yeah yeah well give it to you in December we just can't give it to you in November all right and get rid of that one and that one in the middle you can get rid of that one too you know that one second from the beginning it's a real shame you did that one because we sure don't need it that's bad yeah we don't want to hear that one again we never wanted you know invest in work that we don't need to deliver by the date so from now on every time we start a new sprint we're going to the stake holder and say which one of these do you want us to start next we don't care you know we're programmers we can deal with all the weird stuff like you want logout before you want login that's fine we can do that because we're programmers we can figure that out just tell us what you want first so that we never ever deliver something you don't need that's agile that's agile at the 30,000 foot level agile is a simple technique you take a project you subdivided into time boxes you measure how much you get done in those time boxes you use that measurement to project the end date and then you manage and manage and manage because every software project is always a horror scene they're all going to need some kind of management because we don't know how long anything is going to take really anybody here good at estimating yeah there it is six months why aren't we good at estimating what's the problem here why can't we estimate software they can estimate other things why can't we estimate software how long does it take you to tie your shoes seconds how long would it take you to write the instructions to tie your shoes you can't even begin to estimate that can you you're gonna control some robot some Lego Mindstorm thing you're gonna write the code to tie shoes how long would it take you to write that code you can tie shoes this is the problem with with estimates we have to tell a how to do something that we can do intuitively we're gonna produce a report about you know bank interest well stupid as simple anybody could do it a kid can do it if you want me to write that report for you I'll write it by hand it'll take me a day okay write the code for that I can't even begin to estimate that because I can't begin to estimate how to write the instructions to tie my shoes same thing it's the same problem we don't know how long this stuff takes now we can make guesses and I told you yesterday about the three numbers the three estimation numbers that's helpful but you should never forget that those are really wild estimates they're just guesses the guesses get better with time so as you go along from slice - slice - slice to slice you get better and better at those estimates because you start reducing the variables and that's another reason why those graphs can have little bumps in them our estimates promises it can never be promises never be promises you cannot promise to deliver fixed scope by a fixed date with fixed quality and fixed cost you can't do that that's the Iron Cross the best way to manage that situation is this do it in lots of short cycles get the bad news as early as possible and make no mistake about it that is exactly what agile is for is to get the bad news as early as possible it's not to go fast just to get the bad news early the disciplines of agile are on the screen here these are the agile disciplines come from a a process that was called extreme programming from long in the past extreme programming was one of the agile methods there have been several over the years scrum is another feature driven development is another crystal is another dsdm is another there's a whole bunch of them but the best defined is extreme programming it's the one that defined all of the different parts of an agile project the green outer ring those are the business facing practices and that scrum the green ring is scrum scrum as an agile process is in a business facing process it doesn't deal with the internal as much the red inner circle that's the engineering practices the programmer specific practices and the blue stuff in the middle those are the team practices that's how a team behaves those are the disciplines used by a team scrum is just that outer ring scrum without the inner rings has a name it's called flaccid scrum scrum that fails and what are the symptoms of flaccid scrum closets drum starts to work initially just fine you go through a few sprints everything seems to be fine the team is making good decisions there's good communication with the product owners and so on everything's going along fine and then you start to see the team slow down and thus team the team gets slower and slower and slower with time why does this happen because they're not practicing the engineering practices in the middle the engineering practices in the middle are the things that keep this the architecture and the design and the code clean and without that scrum will slow down and grind to a halt it turns out the scrum is a really efficient way of making a mess really fast unless you augment it with the engineering practices in the middle now this has been known for 15 years the name flaccid scrum was invented by Martin Fowler fifteen years ago it's been a well-known term most scrum teams nowadays adopt the engineering practices some don't and that's a problem so let's walk through these practices one bit at a time I'm not going to get to them all I do want to get to the the green ones because the green ones are the most interesting from our point of view and I've already talked to you about test-driven development I've talked a little bit about refactoring so this stuff in the middle we can bypass for the moment the practice on the far right is called the planning game this is mostly what scrum is about the planning game so let me just let me describe how this works we're sitting the developers and the stakeholders together in a room we're one small team agile by the way is a is a method for small teams to do small things agile is not a technique for big teams to do big things is a method for small teams to do small things if you want to do big things you have to use a lot of little small teams and all the small teams are doing agile some people worry about things like agile in the large I'm not sure there is such a thing there are as agile in the small that's how agile was first defined and it was the goal of agile to solve the problem with small teams can you do agile in the large I'm not even sure I know what that means can you get many small agile teams to build something big sure sure but you have to use agile to do that at some greater level no I don't think so we've known how to get small bunches of teams to work for years you know we built pyramids we went to the moon we know how to do that kind of thing agile was just about small software teams doing relatively small things so here we are we're a small software team gonna do something relatively small and we're sitting with our stakeholders and we start to have a discussion what is this what does this system have to do now let's say that we're building the software for an automated teller machine so we start talking about the the requirements and stakeholders say uh well customers need to be able to get money okay so you mean you want to be able to pull money out of the slot yeah oh it means you're gonna have to enter your bank account right yeah and and the amount of money you want to take out right yeah yeah and you better be able to identify yourself maybe with some kind of a card and a PIN number or something like that yeah okay and by the way that whole identification thing you're gonna need to do that for just about everything aren't you yeah well that's probably a different story then so let's deal with that story we should call that story login login okay done now we don't talk about the details much oh we might discuss them verbally we might have a little discussion about cards going to slots and pins getting typed in and stuff like that but there's not a lot of detail that we really discuss yet and what we put on the card is just the word login that's enough that'll remind us remember this is a small team doing small things well we need to withdraw money how do you do that first of all you gotta log in and then you enter your bank account and then you enter enter in the amount you want and it's gonna spit money out of the slot might jam but no problems there okay well what are we gonna call this we'll call it withdraw withdraw some customers are gonna want to deposit money to oh what's that money gonna be in they'll put it in an envelope or do they put the envelope well there's a slot for it okay you gonna shove an envelope in a slot how do you know who the envelope belongs to well we'll print something on it okay so deposit yeah that's a good card this is the process that's it a bunch of people sit in the room they have a little conversation about what the what the requirements are what ought to be done there's some details discuss they're not written down we'll get to that later for the most part we're just writing these things on cards and by the end of a day we got a deck of cards now it's not complete more cards will be put in later because every couple of days we're gonna sit down to the stakeholders again and say hey what else do you want this thing to do and they're gonna add more cards to it they'll come to us from time to time so we needed to do this and that and this more cards go into the deck you end up at a little deck anybody here using cards oh good what else would you use is anybody using jira do you say to yourself have you done your jiriz I've heard people talk like that right like the name of the product becomes more important than what you're doing with it have you done your Gira's yet that so that tells me there's a symptom of a problem somewhere like maybe the tool has become more important than the function but never mind that why wouldn't you use cards wow our programmers we automate everything well yeah but why wouldn't you use cards oh we gotta have everything in computers fine put it in a computer if you want I don't care but here's what I'll say about that world war ii was managed on index cards I believe the technique scales by the time Oh a few days have gone by we've got this nice deck of cards there's no estimates on them we don't know how long these are going to take so then we have a little sit-down with the QA people and this developers our team what is our teammate over there's five developers and there's a couple of QA people and there's a manager and there's a product owner and that's the team and the product owner actually is a part-time member because the product owner is a product owner are probably three different teams and that kind of thing happens and that's fine so we sit down with a team and we start estimating and mostly it's the developers and QA people who are doing this and say okay login how long is that gonna take three three what I don't know three just put a three on the card well is that the right number yes because it will take three now we know how long log it will take it'll take three but that's interesting because now we can compare withdraw to log in oh wait a minute how hard is withdrawal take the card read it into the slot read a PIN number compare them spit it out of the slot there's a bunch of stuff to do okay what do you got to do for withdrawal hmm you got to enter in a bank number and an amount and got a spit money out of the money slot and that might get jammed and that's harder and the developers all look at that say yeah that's harder than login five okay five what about deposit you can envelope in and print on it ask him for his bank account I guess that's not as hard that's for four that's the process that's the estimation process and it's quick and it's easy and we use a number of different techniques for this one of the techniques is called flying fingers and flying fingers works like this right all the developers the people are estimating they all sit around a table somebody puts a card down says okay what do you think about withdrawal and we talk about it a little bit or say okay withdrawal is you take money comes out of the slot it might get jammed and stuff like that and then then somebody in the room says okay everybody what's the estimate and everybody puts up some fingers behind their back and then somebody counts one two three and all the fingers come out now if they're all a three what was it for withdrawal five right if they're all a five then everything's fine but if you see around the table there's a couple of twos and a couple of fives rather than there's a discussion to be had and so we have that discussion why do you think that's a 2 it's a lot more complicated in login I don't think it's more complicated log in and they start to have a little discussion and then eventually the discussion ends and somebody says ok let's try that again 1 2 3 oh can you come to some consent can census that way let's go flying fingers some people like to use some planning poker cards fine you can use those if you want to sometimes those planning cards are Fibonacci numbers great whatever but usually you know a hand of fingers is good enough you know you probably don't want to have more than five story might be one might be two three four five that's probably good enough oh this this was probably a reasonable result to write like you know I don't think it's gonna take any time at all and then this one is probably not a bad result it's like I don't know that's a good result because then you can have more discussion so now we got a deck with a bunch of 'its in it are those estimates right log in is the rest of them there okay you know cuz relative estimates are better than absolute estimates programmers are better at doing relative estimation everybody is better at doing relative estimation so okay we've got some esters now we begin the first coding sprint first coding sprint begins with a meeting interation planning meeting should take half an hour meeting starts stakeholders say programmers how many cards are you gonna get done this sprint how many points programmers go 30 you sure you can get 30 done no why just say 30 well you wanted a number we don't know 30 so now the stakeholders pick out cards that add up to 30 login that's a three huh yeah that's pretty important but three is expensive that's like 10% of the budget so we're gonna wait on that one logout one cheap do it yeah deposit for ooh that's expensive put that one aside withdraw that's really expensive five but I want to see the money come out to shoot you're gonna do it this is the process the stakeholders are drawing from this card and they're making a a cost-benefit comparison how much value do they get for the cost and they don't need to know what the real cost is they don't need to know what three means they just need to look at and say oh okay that's that's kind of expensive it's ten percent of the budget alright well am I gonna get value for it mmm look anyway it's a pretty simple return on investment calculation good product owners go through the deck and select the highest value cards that have the lowest cost and that's kind of cool and they'll pull up pick out 30 of them points that add up to 30 okay the rest of the deck just sits over here now we got cards that add up to 30 and now we begin the process of implementing those cards I will talk about that process later perhaps because we don't have that much time but overall the process looks like this one by one the cards move from the ready pile to the done pile now let's say we've got a two-week sprint we've started it on Monday so the following Monday is the midpoint of the Sprint how many points should be in the done pile 15 yes to do this process you must be able to divide by two Monday morning we have a little meeting how many points are in the done pile there's only eight in there and we're not gonna get 30 done are we for lucky we'll get 16 done better call the stakeholder stay callers we screwed up man we said 30 but I don't think it's gonna be more than 16 why don't you take you know you're gonna have to take 14 points out of the pile what do you mean you said you'd do 30 yeah but we're halfway through this sprint we've only got eight done we're not gonna get any more than another 8 done you got to leave us eight leave us the most important eight and of course the stakeholders are very upset by this because a full week has gone by and man that's a lot of wasted time but okay they go through the pile and they leave you with eight and by some miracle on you're actually done with those eight and you've gotten 16 points done and now you put a little bar chart on your velocity chart you say 16 all right we know how much we can get done in one sprint and what do you do is the next sprint begins next sprint begins there's a nice little iteration planning meeting should take about a half an hour everybody sits in that meeting and the stakeholders say how many gonna get done this sprint 16 that's what we got done last sprint they'll do 60 well you said you could do 30 yeah but we got sick all right they pull out 16 16 highest value points they can get now we begin to development and on the Monday the midpoint Monday there's 12 points over there things have been going better should we tell him they're coming to the meeting right it's the midpoint Monday they're coming to the meeting they're gonna look in the dump I say hey man you got 12 points over there you're gonna get 24 points done this iteration and they're gonna come and give us a few more cards and Friday comes along and yeah we don't get all 20 for them then we got 20 of them done little disappointing but all right and so we start the next iteration start the next iteration what do we say stakeholders how many points you want 20 so we got done last time give us 20 now this is the process this is how it goes round and around the loop you just measure how much you got done every sprint that's what you say you're gonna get done the next time it's not a promise it's not a guarantee it's just a little you know help yes where's that thing who's got that thing throw it Oh so why not you take for the third sprint 20 plus 16 divided by true instead of another estimate oh well if you want to do that you can if you want to do some kind of you know complicated numerical analysis and calculus fine you know fine do that the point here is that there's a lot of noise in this signal right you're gonna part paint these bars on the velocity chart and you see as you know a 16 and then a 20 and then a 12 and then you know 18 it's gonna go up and down a lot you'll have to go through several iterations to really see what the signal is but the signal will be there so I mean I might not pay to do a really deep come deep calculation there but you can try that if you want what's happening to this deck it does grow does grow cuz everyday we're adding more cards to it stakeholders say hey we should do this we should do that programmers go to the stakeholders and say hey did you think of that oh that's a good idea stick that in the deck too so the deck is growing what's coming out of the deck high-value cards cards that have high value for low-cost high return on investment cards that's what's coming out of the deck what's going into the deck all kinds of cards some of them have really high return on investment some Beverly low return on investment we're not doing that calculation early on so the deck starts to get low in return on investment the more time goes by the more the more the return on investment begins to drop away there comes this magic moment you start the next iteration stakeholders to their stakeholders look at the deck it's nothing in here worth doing projects over projects not over when everything's done projects over when there's nothing else worth doing and the stakeholders acknowledge yeah there's nothing else worth doing it's remarkable what cards are left in the deck I once worked on a project where the very first card ever written the card that gave the project its name was never played it just stayed in the deck is there was always more urgent stuff to do and by the time the project was over this had lost all importance it's remarkable what remains behind can an iteration fail no iterations do not fail it's impossible for an iteration to fail because an iterations job is to produce data and even if you produce nothing you have produced data a iteration that delivers no points is good data for the managers because boy something's gone wrong better deal with it iterations do not fail if you say and we think we're gonna get 12 points done this iteration but you only get 6 done a theater at the end as the iteration failed no the iteration is simply giving you data iterations do not fail the number of points in the iteration is not a goal you're just simply trying to measure how much you can get done in each iteration now let's look at that velocity graph for a minute what should the slope of the velocity graph be over time slow and steady dead flat we don't want it to rise we don't want it to fall but if you're a project manager what would you like the slope to be going up that would be good wouldn't it if you're a project manager you want to see that slope go up that means you're getting more done with time how can you get that slope to go up guys we got 20 points done last sprint but I believe we can do 22 I know with a little extra effort you can get 22 points done think of it as a stretch goal guys get 22 points now here's the thing that will happen they will get 22 points done but how will they get 22 points done by putting slightly different numbers on the cards because remember these points aren't anchored to anything absolute so then we'll be in Dutch and nobody does this intentionally right it's not an intentional thing you just know you're supposed to get 22 done so you're writing numbers on the cards and humans are what humans are they will write numbers that will fit the first the next sprint might not be 22 the sprint after that might not be 22 but a sprint coming up is going to be 22 and the project manager is gonna go yeah I've got the formula I know how to do this guys it did 22 can you give me 24 now this drives an inflation spiral you come back to that team a year later they'll be doing a million points per sprint you do not want to see a positive slope on the velocity curve unless you can explain it with something like yeah we added three people to the team now that would that that would be a reasonable explanation you know or you know Jim finally figured out how to make the database work that'd probably be a reasonable explanation all right but you don't want to see a positive trend it's a positive trend probably means that someone is putting pressure on the team and pressure on the team is going to shift all the all the numbers so don't want to see pressure on the team especially that kind of pressure what would it mean if the velocity chart is going down sprint by sprint by sprint less and less and less gets done there's a mess somebody's making a mess the engineering practices are not being followed not enough tests not enough refactoring design and architecture are beginning to fail and you want to catch that real early however that one is complicated by the other effect because as the developers start to make a mess and they realize they're going slower or they don't realize it but they feel it they start to shift the numbers on the cards to flatten out that velocity so the way we combat that is this it's very simple that login card that was a three you keep that one around and you're always comparing against that golden login card whatever that card was that you said was a three you're always comparing against that saying okay is how does this compare to login which was a three you try and anchor it against that card trying to do that for as long as you can it is 3:30 we have a half an hour left in that half an hour I want you to ask me questions oh I've been here for two days I have been talking my guts out huh yes sir microphone so every time we deal with this scrum process I constantly start hearing at some point it okay we need to put on the cards acceptance criteria and definition of done and then like it doesn't become card anymore like and of course because in most of the cases there's juror then it's very easy to write a lot of stuff in JIRA so it's really easy to write a lot of stuff in here isn't it and it's great because nobody reads it so it was a good question let me answer the question for you what we really initially write on the cards are just a couple of words right just just enough to remind us a story might be a sentence or a small phrase and we we purposely ignore detail early on but what happens in the iteration planning meeting that half-hour meeting at the beginning of each sprint which by the way is not a half hour usually it's about an hour or hour and a half depends on how long the Sprint is right two weeks sprint two hours probably for the iteration planning meeting during that meeting the details are discussed now who provides the details well the business business product owner is talking to people and business analysts if you happen to have them but the real deep come out of QA QA are the people who are specifying the way this system ought to behave in discussion with the business analysts with discussion with the product owner QA is the one writing down the acceptance criteria the definition of done now they don't write it down in some detail on the card they might write a couple of notes on the card but then the QA people go off and they start writing acceptance tests executable automated acceptance tests written in some language that the QA people can deal with which it doesn't have to be you know a programming language if your QA people are programmers then make it a programming language that's fine but their job then is to write the acceptance test that will define done for every story programmers will know that they are done with a story when the acceptance test for that story pass that's how you know you're done with a story the acceptance tests should be written during the sprint they can sometimes be written a little ahead of time but I don't want to get there yet they written during the sprint we want all of the acceptance tensed all of the acceptance tests finished by the midpoint of the sprint so that the programmers have enough time to finish their stories and make sure they all pass the only stories that can rack up points in the velocity are points that pass the acceptance tests so that's the basic flow if at the midpoint you do not have all the acceptance tests written it means you don't have enough QA people or you've got too many programmers one of the other so it tells you've got a staff imbalance now if it's a temporary staff imbalance a couple of the programmers can jump the line and and help finish off the acceptance test that should take about a half a day if that repeatedly happens well then you probably ought to add a QA person or maybe make one of the programmers a permanent QA person or something like that but it helps you balance the staff did I answer your question yeah good hand it right over to him she's right there good I'm only gonna answer questions in this row here how do you deal with non-functional requirements do you also put them in the car tech how do you deal with non-functional requirements was that your question yes and do you tell the the state colleges that there are also important okay so so how do you deal with non-functional requirements and how do you tell the stakeholders that they're important there are two kinds of non-functional requirements there are those that the stakeholders are aware of for example the system has to be fast now that's not a good story you know system has to be fast that's not a good story so you have to get the stakeholder to put some numerical value on this like we need to be able to handle of thousand transactions per second you can write a test for that state you know QA people can write a test for that so that's a non functional requirement that you put a number on that you can actually test that kind of makes it a functional requirement doesn't the other kind of non functional requirement are those that are architecture related architecture and design related you never say a word about these ever this is like washing your hands after you go to the bathroom you never ever ever go to stakeholders and say well we can get this done in three days if we don't do any architecture you never do that you never say to your boss if I write tests them take me six days if I don't write tests it'll take me three you never ever say that first of all it's alive but second of all it's dumb you are the ones who know how best to get software done well you have little bit flipped in your head that says the only way to go fast is to go well you never ever say anything about non-functional requirements like that to stakeholders none of their business it's part of how you do your work you never ever talk about refactoring we've got to refactor you never say that bosses don't want to hear that what do you mean you got to refactor didn't you do it right the first time never talk about reefing you never put refactoring on the schedule the word refactoring never appears on a schedule ever because you're constantly refactoring you're always refactoring you constantly improving things should I presume that's what you were talking about it good next question oh this row look at that you guys sorry so it's not related to to the topic of but it's something that I mentioned to you before that I would love to hear more because I read already what you have to say about mentoring and I have this feeling that in the software industry we miss a lot of men people that have the skills to mentor others especially developers so the like if you could elaborate on this certainly and if we could relate to the topic of today then I would like if you could mention also about how mentoring could happen for product owners then developers mentoring could happen for for the product owners or the product owners all right take that thing and throw it back there far as you can get it yeah way back there your gadget oh good all right it's in the lunchroom now mentoring so mentoring is the responsibility of the most senior people the more senior you are the more responsibility you have for mentoring for teaching people who are younger than you are really very senior developers should almost spend all their time pairing with other people the most senior people should probably spend their time pairing with more junior people all the time mid-level people should spend a lot of their time pairing with junior people so that these skills can transfer I know of one company where mentoring is is cranked up to 11 right these these this company hires apprentices and they call them apprentices and it's a temporary position you may not actually get hired at the end of this process you will be an apprentice for several months during that period you are not allowed to touch any production code you are given some challenge projects and those challenge projects are fairly significant like you have to write a web server and it has to be multi-threaded and so and you can draw from your mentors there are people that attach to you who are your mentors you can draw from them to learn how to do these things other challenges include giving a talk on some significant topic like a design pattern or a design principle writing a blog about something writing an article about something then these these people having met their challenges will do a journey and the journey will be through several different mentors where they will be pairing with those mentors on at client sites on client software but never allowed to do it alone and at the end of that process which might be three months long it might be six months long the mentors all finally meet and and vote it has to be a unanimous vote to let them become members of the team that's an extremely high bar to pass should that be the way all programmers are admitted into our field I leave that up to you but I think that's an interesting concept you who are senior learn how to teach and by the way I'll tell you a little secret the best way to learn something is to teach it all you have to do is stay one page ahead so all you got to do one page ahead one day ahead the best way to learn something is to teach it so if you're a senior developer start holding classes get a bunch of people in a room and say alright I'm gonna teach you about and pick a topic and then just stay one day ahead them and you'll have enough experience and you'll have enough enough background to fill that with all kinds of useful information that the developers can take away wouldn't it be great if every organization had this this classroom time where the senior people taught the younger people and the mid-level people taught the most junior people I told you before that we have this real problem with the population distribution half the programmers in the world have less than five years experience well this is one of the ways we deal with that lack of information I hope I answered your question anything else I should say oh you wanted product owners ah who are the best product owners best product owners are people who have been burned by bad products and people have been around the block a long time product owners should have a lot of experience because the product owner has this very interesting and very risky role they have decided to put their head on a block and guarantee using their head to guarantee that the product being produced will satisfy the customer so it's a very risky role it's a high responsibility role this takes a lot of experience and a lot of what's the best way to say it a lot of failure the best way you learn that stuff is to fail at it really bad now huh what's a good way to fail at it really badly be a business analyst that gives you room to fail because the product owner can always come in to backfill you usually the business analysts are trying to communicate what the product owner says to the to the to the programmers right so that's a good way to learn how to be a product owner answer your question good all right who's next I've got all that thing to the nearest guy yeah you got it okay good yeah I've got a question about scrum demos scrum demos can a scrum demo define the end of a project that the stakeholders say we're done this is good enough we can ship it yeah really ship it yeah sure why not you do you know it's the end of Sprint demo and everybody's sitting in the room and you've walked through all the features of the product and and the stakeholders saying yeah ship it why not I think that's that's a reasonable thing to do of course all the tests have to pass yeah that's one of the little thing you know by the way who should be driving that demo the product owner better than the product owner if the product owner invites a user in and then says user please drive the demo who should not be driving the demo a programmer a developer because the developers know how to avoid all the crashes right you never let the programmers drive the demo you let the users drive the demo or the product owner drive the demo next question heave-ho yeah look at that that's great Wow look can you me yeah okay if you do a lot of analysis within a sprint how do you estimate that so if you do data analysis and also kind of things you mean data analysis of well in my case it would be to predict something like customer behavior or those kind of customer behavior oh so your your job in the sprit so the story is analyze customer behavior might might be try to provide a predictive well indicator for customers yeah so you've got to come up with some predictive indicator based on customer data yes okay is that a three well to me if you can go on forever because it's analysis so ah I see what you're saying so you need some kind of resolution criteria how accurate does this have to be right and that's that that's the critical number I need to know this data within a 50% margin you ought to be able to estimate that yeah but if I said I wanted I wanted it to within a 20% margin well you might have to take you a lot longer if I said I wanted with no variation zero percent well that's going to take you forever so when you're told give me this data you have to ask okay but what kind of resolution do you want how much error can you tolerate that's true of every estimate by the way every estimate also has to be associated with an error bar did I answer your question I think so maybe partly partly partly sorry good okay to me yes some of its well it comes from the data so you never know in advance one thing we sometimes do is called a spike let me define a spike for you you've got a story and you can't estimate it and you've all had this thing like you got to get the database to work well how long is that gonna take you uh yeah and there's no story I can compare it to I don't know how long it's going to take me to get the database to work I'm just gonna have to try I don't know how long it's gonna take all right then what you can do is you can say let's define a spike a spike is a period of time that you are going to try to figure out how long it's going to take to get the database working now can you estimate that spike I don't I don't want to know how long it's gonna take you to do the database working I wonder how long it's going to take you to estimate how long it's going to take to get the database working so now you've got a new story and the story is to estimate getting the database working and now can you estimate that story I am it's like a three and then after that story's been played by the way they may not play that story for a long time your spike stories don't deliver any value immediately but they eventually say okay we got to get the database working why don't you spend us spend three points on figuring out how long it's going to take and then the next iteration you say yeah that's gonna be a six that's what a spike is for to estimate another story so that's another way you can do this data analysis thing you say okay I need I need three points just to look at the data to try and imagine how long it's going to take me to actually analyze it one more question throw that over here all the way down here hi no all right go ahead all right all right all right and then and then you can go right okay advantageous close by yeah as part of definition of them how do we make sure to include migration script phase or any for testing for example every project do not follow a kind of shippable product every sprint they may do in couple of Sprint's for example in that case how do we include different desk phases within the sprint do we follow it the hard and fast roast rating okay this is my definition of done well okay so you know maybe you've got a process that says I can't run the tests in this sprint because of some reason and I'm gonna have to run the tests in the next sprint and you know how do you deal with that well you let all the stakeholders know that you're not going to be deployable at sprut say okay listen we can't be deployable this sprint because we couldn't run all the tests now this is a breach of the rules right you're gonna break the rules but there's some reason that you're gonna break the rules and it's a legitimate reason if has anybody seen the videos I do on clean coders comm who've seen those videos lots of you okay and you you may have noticed in those videos there's two different kinds of videos there's the the clean code videos where I go through all these rules and principles and patterns and all this stuff and I preach it just like I've been preaching to you and I this is the way you do it you've got to do it this way otherwise you're unprofessional idiots and then there's another branch these are the case study episodes and this is where I sit down or or some other people sit down and they actually write code and the code we're writing is actually fairly significant so it's several hours of watching us write this code but what you will find in those case studies is how we break the rules because we always break the rules the case studies show pragmatic application of the rules and we try to hold to those rules as much as we can but you will find in in every one of those video streams there's times when we just look at each other and say okay well can't can't follow the rules here we're gonna have to fiddle with it and judge it we'll come back to the rules as soon as we can happens all the time so here I've been preaching to you for two days about all these rules and I never did everything right and the best way to go fast is to beat go well and then you always have to remember that this is engineering and there's always trade-offs there's always no I don't want anybody to use that or for a license to say oh Uncle Bob just said we can make a mess because you try as hard as you can but the rules sometimes just cannot hold all the time so violate the rules there was one more question here and then we'll be done yes heights good hi okay it's my question apparently so earlier you mentioned that analysis is what analysts do yes you just mentioned business analysts and I have a lot of business analysts in my department and I was wondering how would or how should they relate to an agile team or maybe face if initely can or shoot they work in an agile team business analysts as one of the hardest jobs there is to be a business analyst it has to be a business analyst you must be technically astute enough to talk to programmers and you have to be personally astute enough to talk to the business side there are a lot of people that are like that who can who can turn it turn both directions and communicate well across that boundary not only do you have to communicate well across that boundary you also have to be accurate you have to be able to put yourself in the position of the customer and understand what the customer needs so that you can communicate requirements to the software development team but then you have to be able to put yourself in the programmers position and understand what they are fighting against and how they need design and then you need architecture and they need tests and they need rigid specifications so it's an extremely extremely difficult role every sprint team needs someone who can play that role on small sprint teams that is the product owner on larger teams are in larger organizations the product owner will usually have many teams that they serve and they will delegate that role to product analysts to business analysts that's the way I define business analyst that's how I would say it so did I answer your question thank you okay in two days and it's not often that I get to have an experience quite like this one this has been unique there's been a lot of work done here a lot of work done the videos you know and the end the look did you notice how well everything worked right and and the schedule of things and how you know the breaks were set up and the lunch was set up and the timing of things and it came in and everything worked and was a nice easy flight takes a lot of effort to make something work like that and then you've got me and I'm a complete prima donna because I wander around the stage and I break all the rules about you know you're supposed to stand in one place when you talk you know and I do all this stuff and everybody who's been just as nice about this it can be I feel as welcomed as I have felt anywhere you guys have been a terrific audience I just want to say thank you to all of you and thank you to you guys who did such great work and I have been told that someone beyond the recognition that everyone else has received here someone here deserves a little extra recognition for being the point person on all of this can I have Kim up here she here [Applause] these are not from me I wish they were but they're from your associates who really value you so everybody let's do that again huh thank you all it's been a great time take a break now you know it is hard to sit in a seat for two days and listen to some guy drone on forever thank you all [Applause]

Channel: UnityCoin

Views: 197,222

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: l-gF0vDhJVI

Length: 98min 9sec (5889 seconds)

Published: Fri Aug 09 2019