How Do I Estimate Tasks Correctly? How Do I Estimate Time Accurately?

welcome to this episode of Dev questions with Tim Corey join us as we tackle the questions you are asking about a career in software development understanding the industry and new technology if you are just starting out or you want to grow stronger as a developer this is the place to get your questions answered now here's your host expert developer and online educator Tim Corey how do I estimate tasks correctly how do I estimate time accurately this this is a question was asked on the suggestion site and it's one that I think it's really important to talk about because you're going to find out it depends all right so let's talk about it in today's episode of Dev questions again if you have a suggestion you want to see answered go to suggestions. timc cory.com leave it there and hopefully you'll see your question answered in a future episode of Dev questions now how do you estimate task correctly and how do you estimate time accurately for software development well you don't there's your answer all right see you have a nice day um estimates are often seen as guarantees this is the the real trap it's kind of like when you show a customer a you know a drawn out user interface or maybe create a temp user interface and say hey this is what we're trying to build is this right and they go yes let's go put put that in production you're like no no no that was just a an estimate that was just a a sketch and they're like no no no I want to see that in production tomorrow because they don't understand the difference between creating a rough something and creating the actual final thing well the estimates what is seen as an estimate is actually assumed to be a guarantee as in I think it might take us about two weeks so two weeks goes by and they're like okay where is it I want to see it right now you're like well we had some you know slowdowns or whatever and they're like okay so you're not a good developer then right because you didn't do what you promised well it wasn't a promise it was an estimate so that's why estimates are really a trap so estimates are not guarantees all right and this is where some confusion comes in about what software is and what it's not when you're building it so building software is like building cars from scratch each time with different specifications you see if you are looking for a Toyota Corolla well Toyota can tell you how long it takes to build a Corolla because they have an assembly line they've built them over and over day after day week after week month after month and so they know which parts go on in what order and which parts to to have made and what the shapes are and all the rest of everything they need to build a Corolla but if you told Toyota hey I want you to build a different car every time this time I want a Corolla but you know next time I want like something totally different maybe something with six wheels instead of four maybe something with an engine in the back or maybe something with a different structure maybe it's a truck this time or a van this time well they couldn't estimate how long that would take right because they know how much a Corolla takes because they've done it over and over and over and sometimes people think well that's a software is Right you've you've already done this over and over again just do it for me and use the same time frame but that's not what we do at least not in most cases in most cases we're building something from scratch so we're building a thing that is similar an application but it's like building a car with different specifications the basic parts are probably all there but how they fit together and how they're specifically constructed is going to change from vehicle to vehicle I can't take a bumper from a Corolla and put it onto a truck doesn't work that way so that's how we build software is building a different thing every single time estimates are always going to be guesses no matter how much structure or planning you'll you'll never get truly good estimates and there are some systems in place that people say well this gives you good estimates we're going to do story points we're going to do you know something else to try and figure fure out how to structure this to really give us a good estimate but the reality is they're guesses the absolute best way the best solution to the problem is to break a project down into Tiny Steps now Tiny Steps are easier to estimate because there's very little that's unknown okay you pretty much know everything about how to let's just super simple example I want to build an if statement well I can figure figure how long it's going to take to build n statement right and I need two of those and I need a for Loop okay that's pretty simple to to break down an estimate but there's little unknown there but if we're going to add it all up those tiny estimates could in theory give you a decent estimate however at that point you've already architected your entire application and you could have just built it plus that fails to take into account the assumptions that you have that are going to be wrong okay when you build a project you almost always have assumptions that have to get changed maybe it's the client saying well we actually want it this way I've had clients that say well I know we said desktop we really meant web well that's a problem because now all of our estimates are based upon something that's going to have to change entirely or mostly so that's a big deal but it's also sometimes where you're saying hey I think we can just do this authentication thing we just drop drag and drop this thing in you find out o it's not quite that simple we have to do something else and that's going to take some more time so that's where it's going to fail to take into account some things that might cause major differences in your time because now you got a cascading effect you've mapped out the entire application in minute detail in order to get a great estimate and then you find that a quarter of the way in that something is different then you have to change and now everything from there on down has to change as well because it's based upon the thing that you changed so now three cors your estimate is no longer valid even with that tiny little estimation system where you're estimating every little task so even that is not going to be a perfect system so how does software projects ever launch on time well the answer is most don't okay however there are ways to meet a given deadline so be careful here because there are ways to meet estimates as my boss used to tell me and tell customers all the time time money and quality pick two so there's ways to meet the deadline but it's by manipulating one of those levers okay so time you can spend more time on the project or you can extend the Dead line okay so maybe you're working 20 hours a week on a project you work 40 instead or maybe you push off the deadline to a later date which kind of would usually miss an estimate if you're saying the estimate is time like will be done by May 1st but sometimes your estimate is how much money you're going to you know spend on this so you can push off that deadline and say hey we're going to still work 20 hours a week but now we're working through until July 1 instead of May 1st so you have two more months to put in the time necessary to complete this goal that's one lever you can pull the second lever is money you can hire more employees on the project or you can have them work overtime or things like that or you can buy parts of the project instead of building them maybe you decide that please don't do this but maybe you decide we're going to build this database on our own we're going to build our own our own database type instead of using SQL or mongodb or one of those database types we're going to build our own because we know best how to build a database if you get tight on time well you can buy a database instead and you can use that instead of trying to do the whole thing yourself or maybe it's authentication don't roll your own authentication but maybe it's authentication instead or maybe it's you know a piece you can buy a control from some company to drop in a place to do that or most of that instead of doing it yourself okay so that's money you can spend money on people or on things to speed up your process or the third lever is quality you can remove features or reduce the scope of your project this is a pretty popular one so we want to have this application that you know maybe signs people up for this guest book and it's simple application just a guest book application for weddings and you want to be able to have them upload images and upload videos record videos in the spot and so on for the guest book well maybe what you do is say okay we can do text messages like type it out or we can do images and text messages but that recording videos thing that has to be pushed off until version two we just don't have the time to be able to get that in for version one so if you want to get this project out the door by a certain date and you don't want to spend more money buying things to put in place we could cut out the video portion but get the rest done in time you'll see things like games do this a lot where maybe they wanted to have both a single player Mission as well as multiplayer and they might cut the single player until later or they might cut the multiplayer until later and they say we'll just do this part of it for launch so this a pretty common thing it's time money or quality and you can pull one or more of these levers in order to hit a deadline of time or money okay so how do you come up with estimates if things are always shifting you really are just doing a guess and you have to manipulate one of these three things in order to really meet a arbitrary deadline well here's my way of estimating things number one identify things you've done before so let's just say you know talking to a SQL database I know how to do that I've been done it before then a lot of times I have sample code that I've done before maybe from another customer so I can just you know reuse some of the things I've already done therefore I'm pretty sure I know exactly how much time it's going to take do that estimate and add 50% or more okay A significant margin so if you think that'll take three days make it five okay make it a full week if you say well it's actually going to take you know only a day really let's do three days let's make it sure we have a bit of a margin here and you say well 3 days is more than 50% yes when you get so small then a little extra doesn't give you a whole lot you see if if we could estimate in a week time frame well if we had to we have the weekend okay we have two spare days that we could potentially work overtime to make sure we meet that goal so that's things that you've done before number two research the things you have not done before so if you have not done something before maybe adding authentication into a mobile app well do that do it into a test project figure out how it works figure out the ins and outs of it and then once you figure out your time frame add a large margin i' es me 100% or more so if you say that's going to take a week make it two all right that way you're sure to have some buffer time in there and here's the thing at the very worst where you say you know what we've got all this done early then great if you're done early the customer is not going to complain that you've done the application early at the worst case is that it's done early and you sit around and wait for that that deadline now on the other end if you don't do a good job estimating you're cutting things out you're adding more people you're stressing out so that's the worst on the other end which is if you can't get it done in time which is why you should know how long it takes first now number three add all those estimates together and present that to the client so if you've add your one week and your two week and your four weeks and you figure it all out you say okay it's G to take us eight months to get this project done probably you should be confident in about four months so you say I'm pretty sure we can get this done in four months maybe five but you say eight okay so get it together and present it to the client and then communicate clearly that this is an estimate not a promise okay so communicate clearly we're going to try and hit this date we're going to do these things to make sure that we're doing our part to hit that date like working this number of hours per week making sure that we're checking in our schedule making sure that you know we're communicating whenever we have something gets behind all those things are important but communicate clearly this is an estimate a almost like a guess not a promise okay it's an informed estimate but it's not a guarantee now number five if they want that guarantee or a promise to say we're going to hit this date so if if they say you know what no I need to know for certain you're going to hit a certain date then maybe even right in front of them say okay we at eight eight months from now it's now a year add 50% now you've already overestimated add another 50% right in front of them and they say whoa whoa whoa whoa I want done in eight months well then let's start cutting things because we cannot guarantee that 8mon dead line if you want a guarantee we need to shrink things down but if you want a guarantee we're going to go with 12 months we'll guarantee it in 12 months time not eight add that 50% right on top of you're already above the top estimations okay and then communicate they might not get all their features or might cost more so quality or money because they're asking for a specific time you're still saying this is still a bit of an estimate even though you want a guaranteed date sure we'll lock in that date but we're going to maybe spend more money or take more of your money to make this you know easier for us to do or it might be we reduce some features in order to get the core thing out the door by your estimate now you try and get everything out the door my my thing as a as a consultant was always to under promise overd deliver if you say it's going to take a year and it takes 8 months the the client is ecstatic if you say it's going to take 6 months and it takes eight months the client hates you so always under promise and overd deliver give yourself plenty of padding and then use those three levers to try and make sure you hit whatever deadline needs to be hit but always communicate what you're going through and what what's coming up that might cause problems to your deadline of time or money okay so that's the way I estimate because estimates are pretty much guesses and so the way I do is I always try to even to myself under promise and overd deliver always give myself more time than I think I need because as developers we often get into this mindset of oh that's easy that'll take a day you know the weekend project you know my wife Chuckles at the weekend project because that weekend project is a month you know if oh it's just a weekend project okay that's a month because we always look at a problem and only see the the parts that we we know the the easy parts we forget about all the hard things and all the work that goes into connecting everything and debugging problems and so many other things that happen throughout the life of a project okay so that's my recommendation on how to estimate things okay thanks for asking a question thanks for listening as always I am Tim [Music] Cory

Channel: IAmTimCorey

Views: 7,292

Keywords: .net, C#, Visual Studio, code, programming, tutorial, training, how to, tim corey, C# course, C# training, C# tutorial, .net core, vs2022, .net 6

Id: zPAC1CFdW9s

Length: 17min 50sec (1070 seconds)

Published: Thu Oct 26 2023