Detailed Notes
In this episode of the Building Better Developers podcast, Rob Broadhead and Michael Meloche dive into the often-overlooked topic of setting deadlines—and how it can make or break your business projects.
🔹 Learn why setting deadlines is more than just a calendar entry 🔹 Discover the psychology behind hitting (or missing) due dates 🔹 Explore Agile vs. Waterfall timelines and when each works 🔹 Get tips on client communication when things go off track 🔹 Hear real-world stories from the trenches of software delivery
🎯 Challenge of the Week: Define what “done” means—to you vs. to your client. Then outline every step between “code complete” and “customer-ready.”
📬 Have feedback or questions? Reach out: [email protected] 🌐 Visit: https://www.develpreneur.com Read more: https://develpreneur.com/setting-deadlines-business-projects/
🔔 Don’t forget to subscribe for more episodes on building better developers—and better businesses!
#SettingDeadlines #ProjectManagement #AgileDevelopment #SoftwareDelivery #BusinessStrategy #Develpreneur
Transcript Text
[Music] We are recording. We are live. Um, full disclosure, been a long day. we have had some caffeine, but now it is uh cocktail and wine time. Um, so this may be a little bit different from what you're used to. Uh, and if so, hopefully in a good way. And if it's a complete train wreck, may you never see it. Uh, welcome back. We are here developer trying to figure out what we're going to do this time around. I'm going to look at some ideas you threw out here because I was thinking they were pretty good. something around self-employed deadlines or when the project falls behind, how to recover. Um, that's actually a really good one. We'll come back to that. Let's see. Let's see that one. Or it's okay to take a break when you're stuck on a problem and the problem will still be there. That's one we've done a bunch. So, I think we I like it, but we may come back to it. How could we do that with business? That was we we've done a lot from the other perspective. I I thought of this from a business perspective. So, and I think that's your next one. You said when to take a break. PTO is not just for employees. I think I like that one a lot because my company does not actually have PTO. We have an open PTO policy. You take it whenever you want, as much as you want. Initially, I did the standard like when you start out, you get two weeks PTO and then you get another week of sick leave and stuff like that. Now, part of it um this will be bonus material before we even get into it. Part of it was I had two employees. My primary employee, my senior employee that had been there a couple years was going through cancer treatments and so was not I knew he was going to blow out sick and PTO and didn't want to lose him. And so for many reasons um happened to be my son. So we'll just like add that little piece. Um, so I was like, you know what? I'm going to change the policy. And part of it was like for myself when I was the only employee, I didn't feel I was like, I'm I'm never going to take that much PTO anyways and I'm not going to pay it out and there's just so much involved with it. I was like, you know what? Instead of worrying about tracking it, I'm just going to say we have an open policy and we'll just like if you don't get your work done, we're going to have a discussion. And this has been I think I'm a year and a half into this maybe and it has not been abused. Now granted, I'm still a small company. They're they're so somebody gets hired and wants like, oh, I'm going to go work for them. I'm going to take PTO for 6 months. You will be fired and I will like change my policy. But for right now, it's pretty it's it's wide open and it's worked. But I think that actually gets into the whole like but you need to take PTO. I have I have talked to so many people in the past. I've been that person at some point. Now, early on, I got paid overtime. Once once PTO was you had 80 hours with first place I worked, you had 80 hours and then once you got another 80 hours of comp time, you got paid overtime everything after that. So, it was awesome. I was starting out and I was able to like work my way into higher wages for like two months and then they cancelled that whole policy which really ticked me off. But I had a lot of PTO and what I ended up doing which most young people do when I went to a new job I basically got paid for my remaining PTO. Now some people you don't get paid so you get forced into it but I think that's like a really good conversation to have about that. So I don't think I don't want to get into spoiler alert with that. I think I do like um I want to tweak this first one something around self-imposed deadlines or when the project falls behind and how to recover. I think I want to talk about setting deadlines. I think let's keep it like broad like that and see where it goes because um there's a lot in that. There's a like some of the stuff I'm working with right now and and different projects and stuff like that and how those things work. So I think that um we may actually be able to provide some insight into that. So these ideas came from Yeah. So, six fingers, four fingers, two fingers. This is going to be a fun one, folks. Buckle up, buttercup. We're going to have a ride. Hello and welcome back. We are the building better developers co podcast. We are building better developers. We are also developer. I happen to be Rob Broadhead, one of the founders of developer, building better developers. This season we're building better businesses. This episode's going to be I'm just going to be like upfront. This is not caffeinated. We're on the other side of the day. So, this may be a little different. I apologize if this goes off the rails. I am going to give you a little bit of a spoiler alert. We're going to talk about setting deadlines. So, this is going to be something that um I don't think we've actually touched on too often. We've talked about project plans and stuff like that, but this is like like the deadline. It's like this is the finish line and and defining that and and sticking to it a little bit as well. So, little spoiler alert, that's where we're going to go. First, I want to also mention because I'm me. I am also the founder of RB Consulting where we are all about honestly we're all about you. Whatever your company is, our approach is we're going to sit down, we're going to talk to you, we're going to understand what your business is. We're going to figure out what is the recipe for success for you. This is not like some recipe you get off of Rachel Ray's 30 minute kind of stuff. This is specific for your business because we have found that each business has its own secret sauce or special sauce, however you want to look at it. There are unique things that draw your customers to you. There are unique things that you do for your customers. Now technology happens to be a huge investment for any business. And so what we do is we figure out your business, we talk to you, we understand, we learn and then we take our experience with technology in the world that's out there and we help you through integration, simplification, automation, innovation, whether it is buying something off the shelf, whether it's building a team, whether it's building custom software, we help you get there so that we can provide you a technology roadmap and plan that is good for today, 6 months from now, six years from now. We help you take that technology sprawl that everybody has to deal with and simplify it down into something we can put a nice little pretty bow on and hand over to you so that you can get the best ROI on what is other than your employees probably your biggest single investment. Good things, bad things. This is actually funny because in the green room before we stepped into the show, Michael and I had a long conversation and it really is the ultimate of good thing, bad thing. Uh this is actually also what's going to be in the newsletter which I have not finished yet but it will be out probably by the time this thing comes out. Um it is a busy season right now. We are blessed and cursed by having way more work and things than we have hours in a day. So the good news is for me in particular I have got a lot of work. It is meaningful. These are projects that are not just like throwaways and stuff like that. I've got some things that really matter to my customers. I'm very happy about that and I've got a lot of them. The bad thing is that I have probably too many of them and so I am getting up early and staying up late to make these things work. Now, I guess as a side note to that, bad news, I am too old to keep doing this stuff. So, I'm going to adjust. The good news is is that I am going to be able to separate myself from some of these projects to downsize myself essentially and be able to stay sane while still providing the kind of quality that my customers honestly uh they expect but more honestly they deserve and what I strive to give to them. And so this is one of those things that I think it is it is something we will probably at some point talk a little bit more about this in in one of our episodes is the balance between and we've we have talked about a little bit like when you grow too much and you need to bring other people on. But there are there are some other factors that are involved there is like it has to do more with quality which Michael loves to talk about. So I'm going to use that as a segue to toss it over to him and allow him to introduce himself. Michael, introduce yourself to the crowd. Thanks, Ro. Hey everyone, my name is Michael Malashsh. I'm also one of the co-founders of developer, building better developers. I'm also the founder of a company called Envision QA where over the years I've spent many many hours working on different projects either be it in the trenches writing code working on testing and I've learned that if we build software or come at projects from a tester's point of view it we can build better more refined software for our customers. So, my company's focus is to work with small to mid-size businesses to help you understand what the technology is that you're struggling with with your business. If you need additional software or if we need to throw that out or build something custom, we help you figure out how to make your software work for you and make your product a better solution for your customer. Good thing, bad thing. Bad thing. I I'll start with bad thing. Bad thing is I am it's good and bad but more bad at the moment. I have so much work to do to meet all the demands on me that I have not been able to spend as much time as I would like living life. And we've talked about this in other podcasts and other episodes. And stress and anxiety are a burden when it comes to being overworked or overextended in what you're trying to do. And I I'm in that right now. Um, with that being said, the good side of things, it warmed up today. We're kind of in that warm side of spring again. Although this morning we were freaking 36° again. By midday we're back in the 70s. Uh I hate Tennessee weather some days. Throw a rock. It can be one season every hour. Who knows? Uh but the good thing is I took a break this afternoon, walked the property. So I was worried because we kind of did have a weird winter that we lost a whole lot of trees. We've had a lot of bad weather lately. I I just decided, let me just take a walk. Walked around. It was sunny. It was warm. It was quiet. Well, sort of. The birds were going wild. Uh we have lots of birds, very happy birds. Uh we we're down to two guineies from four. Uh it it happens on large properties. Long story short, by the end of the walk, I sat down on our dock over our pond. And I just sat there for about 10 minutes, just reset. It was such a nice day. I kept thinking to myself, "Okay, I need to go dig a line, run Wi-Fi out." Of course, I go back to work while I'm sitting there. But it was a great kind of reset to realize there is a purpose to what I'm doing. It's not all about work. So for those of you watching this, remember that you know there is a light at the end of the tunnel. It's not always a train and we are doing this for a reason. It there our lives matter. What we're doing matters and that's the good to the bad. Okay, Michael's going to go back to work now. I will say that was actually another good thing is that I was testing today. Um, I don't know if you were I think you were on the call because I was working from my I was using Zoom on my phone and I was like, I'm going to go sit out in the sun for a little bit and test whether I can use my iPad and my phone to do some basic work. Now, I will promote even though we get nothing out of this. If you have one of the, and I don't know how far back this goes, if you have one of the more like the recent generations of iPad, there is a keyboard and protector combo with it that has a glide pad on it. It actually is a full keyboard plus glide pad, and it works pretty darn good, as they say around here in the South. Um, I highly recommend it. I think it's I don't think it's cheap. I can't remember how much I paid because I like got several of these things at once. 125 bucks. I was gonna say it's like 120 to 200 bucks depending on what you get, but it's actually from a a tactile point of view, it is actually a really good keyboard. Not my favorite keyboard I've had for an iPad. Uh the one that I wrote the book on was a was much more like a tap tap tap. I like a harder like a more, you know, resistant plastic kind of keyboard. This is a little more rubbery, but it actually is really good. The uh the case in general is awesome. This will be one of those. Shoot me an email at [email protected] if you want more information on it. I would be glad to share that with you because it's just really cool. I think it is. I think we are literally approaching a point where technology is good enough that we really can go work like out on the dock at our pond and stuff like that. And these are some of the things that we need to do. But right now, we need to get back to the the topic because I don't want to like, you know, scroll into what's the topic? What was the topic again? Um, I want to talk about deadlines. And this is this is an interesting psychological kind of topic in a sense. And I'm going to start it by why why I said it's psychological is I'm going to go back to a little story about um a person in my past that was habitually late and happened to live in the same house that I did. And so what we did over time is uh I would sneak in and I would set all of the clocks 30 minutes ahead of schedule because this person happened to be 30 minutes late. Now, the problem is at one point this person figured that out and so I ska I moved the clocks further ahead and the next thing you know people would visit our house and go, "Why are your clocks an hour and a half ahead of time? What is wrong with my watch?" And I was like, "No, this is on purpose." And I would have to say, and it's probably giving it away. She would also say, "Yes, it's because we wait till the last minute sometimes as a family to get stuff done and to get on the road and to get like get to wherever we need to be." Now, I say this because there is obviously with a deadline when we set a deadline, there is the we need to do this by this point factor of the deadline. It could be things like um we have to get this done by this date so that the follow-up people that are going to you know we have to get this product done by this date so that all of the people that build all the marketing stuff can get it done so that it can ship in time for Christmas or whatever it is you know things like that. There are also deadlines like we need to get this done because we need to beat um a change in some sort of like government requirement or something like that. It may be something we need to get this done by a certain date because then that is the time that we've told everybody that we're going to get it done. There's a lot of reasons and they may be very hard reasons or very soft reasons. And then there's also the psychological stuff of we need to set a deadline of Friday because we know that if we set it for Friday, we're not going to be able to get till it till Monday and Monday is actually our d, you know, deadline or something like that. We're always, you know, x days late or if we don't set this deadline urgently enough, everybody's going to dillydally and then we're going to, you know, we're not going to we're going to wait and everybody's going to study the night before the exam to get it done. Now, some of that actually is uh built into the agile approach very much. Some of that is the agile manifesto. If you look at some of it and the idea of delivering sooner rather than later, they don't say it, but it really it does sort of imply it and addresses the whole I'm going to wait till the night before my project is due to actually get started on my project. And this back when it was done, most projects were 12, 18, 24, 36-month projects. I mean, these were not small. These days, those are practically unheard of, at least when they start. I've been a part of a lot of projects that are like, we're going to get this done in two months. 24 months later, we're still working on it because people just didn't estimate right. So deadlines, I want to talk about I really do want to talk about more the the psychological part of it. I want to go to what is how do you set a deadline based on we'll call it the real deadline because these are some things that honestly every team is a little different, every group is a little different, every personality is a little different. So for me, there are deadlines I can set for myself because I know who I am. I know what my prop propensities are and things like that. I know what I'm going to likely do. And so I know I need to get this done because if I don't, then this thing's going to come up and life's going to interfere and all of these other things. And I want to just like give a couple of factors for setting a deadline. Now, one is this is this the first one is probably the hardest is look at the actual deadline and then it's called uh contingency planning and backward scheduling. So, if you have to have this done by January 1st, what are the tasks that are required in order for that to be done by January 1st? Now, usually when we're building software and we're providing a service or things like that, we have a we're not done. When we get done, when something is code complete, there are other things that go on. It may be this thing some people have heard of. It's really rare. It's called testing. Uh but there's also packaging. There's also deployments. There is training. There is user acceptance testing. There are a lot of factors that can go on if it's a this may age me a little bit but or date me a little bit but there was a day when people would build products and they would have boxes and manuals and things like that but even now like if you're going to have a manual even if it is not physical but a digital manual you have to provide time for that to be created for that to be vetted tested validated and things like that not Oblivion Oblivion was Like, wow. That was almost 15 years ago. 11-1 111. I will never forget that. That was when it came out, right? Or was that Skyrim? Uh, that was Skyrim was 11-11. For those of you listening, I did show a box copy of Oblivion. I'm sorry. So, Oblivion was actually before that. Wow. Oblivion was like 03 or something. That is literally like 20 years old. That is probably an antique that you just showed us that you have the box for that regardless of what a system. Okay, slight sidetrack. Okay, back to deadlines. What you need to do and this is actually the most important exercise of setting a deadline of setting your deadline versus the real deadline is to go through the exercise of what is required to happen once I get we'll put it in air quotes for you as a YouTube you see it the rest of you it's air quotes what is done what is code complete is usually the more complete the like accurate term when I go from code complete, what are the tasks that have to occur to go to this is done complete shipped or something like that because I have found too often those steps are not taken into account and what you end up doing I'm going to give you from a visual point of view is like if this is your deadline so if you haven't go check us out on YouTube this is your deadline is your fake deadline this is your like assumed deadline what happens is usually you're up here, but this space here is what is needed in order for you to actually get to complete. There's so many things and this is why testing is tossed aside way too often is because people get to the end of a very complex project that somebody and I'm going to be like judgmental right now. Some said, "It's going to take us one month to test this 18 months of coding, this million line of code product. They're going to be able to test it in a week." Not going to happen. Only if you have the requirements you need. That's a whole another road. All right, we're going to go way out script on like we're getting a little off. Um, that's a problem and I think that's the challenge and that's really my focus in this if there's nothing else and this is a little bit of a hint a spoiler to the the challenge is it's it's not as much about the deadline. It's as much about defining not only the requirements but actually like fully defining requirements. what are not only the requirements to build the product, but actually to ship the product, to deploy the product, to dis to train the users to actually get it in production. And now I'm going to let you like mull over that a little bit while I have a little sip of my drink and Michael provides your thoughts on all this because I know you're like you're at the back end of that. You like you're the the horse's rear that gets kicked all the time in the testing world. It's like, yeah, take that, you know, you made six weeks of testing scripts. Can you get those done in a week? So that sets the table probably really nice for Angry Michael to step up and talk about testing. So yeah, so you set the table really well for kind of defining the approach to setting deadlines. Now Rob mentioned agile. He also mentioned waterfall. If you watch the pre-show, the the big thing is when you are building software, there needs to be some idea of what it is you're going to build. But at the end of the day, you need to know what are you delivering. And somewhere between the beginning and the end, you need to lay out a road map of how you're going to build it, how you're going to reach those features from concept to completion. We all run into this. In fact, we're in the middle of a project right now that has kind of gone off the rails multiple times, but we're still moving forward. That is the beauty of agile. However, there are benefits to waterfall 2 where you spend a little more time at the beginning flushing out all the requirements. You get all the requirements defined. You flush out all the tickets you need and then you start working. Okay. From a new project perspective, Waterfall, spending a little more time at the beginning to do that may be a better um better start to the project for defining the deadlines to defining the requirements so you know when the deadline is actually achievable. For an existing project, yeah, you're you're already in it. You're in firefighting mode or you're in maintenance mode or or feature mode. So that's a totally different beast. So there you want to go through those cycles. You want to go through those sprints. You want to go through quickly, make changes, keep things moving, keep things forward, keeping features going out. So Rob mentioned testing and that's my wheelhouse or has been my wheelhouse for the last decade but I'm still in all phases of development which is where I struggle from a company perspective coming into a new project I want to build the perspective uh upfront the testdriven development approach. So we need to define or flesh out most of the user stories before we write code. There is a difference between user story and requirement. User story defines how the users are going to use the application at the end of the day. That is what you need to deliver. Now from the user story to the setting deadlines to the deliverable that is the importance. If you can flush that out it could be more requirements but if you can define all the user stories upfront you will be in a much better place to say okay we have 150 user stories. We know 80% of these are small features. They're very quick to knock out, but 20% of these could include like a data migration. Data migrations could be easy. They could be hard. Or you could be dealing with a 30-year-old system that is soraic and you are not sure what you're getting into. It could be nice. It could be bad. It could be the seventh layer of hell. Um, which unfortunately is where we find ourselves sometimes. Um, so setting deadlines, and I digress, but setting deadlines is an art that isn't always perfect. You're going to get it right, you're going to get it wrong, and you're going to be so far out in left field that you might look for another career. But bear with it. It is not always perfect. You want to kind of stick with um what is it? Perto, not that's the timing thing. Um the word he's looking for is pomodoro. Yeah, but you thinking the 8020 rule. Who? Oh. Um crap. Dang. You just made me lose that one. Um but anyway, stick to the 8020. try to deliver 80% of the project. If you start out saying, "Okay, I'm going to set my deadline and I want to meet 80% like meaning this is going to give us most of the features." You are setting yourself up for a better delivery. However, as you're doing that, you got to remember you have 20% left. So when you say okay we can get this 80% done say in six months you better be tacking on another two to four months after that for that 20%. That 20% could be one month it could be eight months. The reason I say this is there was a study done years ago with airlines to improve customer satisfaction. All airlines had to do was increase the time of the flights to make sure that if there were any delays or any problems, the flight still made it on time. But 80% of the time the flight is early. So they have padded the flight times to ensure that customer satisfaction is going to be high because they're always or in most cases going to be getting you to your destination before the time you need to be there. Now there are always the situations where you don't meet that deadline. And if you don't meet that deadline, we've talked about this in the past as you're going through the project. If you start seeing this going off the rails, make sure you communicate with your customer at every step of the way. Make sure you have weekly conversations. Make sure you have daily conversations. If things are on fire, if things are not happy, you did a demo, they're not happy, make sure you include your customer as much as you can to ensure that yes, we are addressing this, we are touching this, we are ensuring we are on the right path. So setting deadlines isn't just about ensuring that, hey, when I go into this contract or this proposal, this is when I'm going to get done. Also, you need to make sure that you meet that deadline or that you address any changes to the deadline as they occur through the whole process. What are your thoughts on that, Rob? My first thought is paro principle. P R P A R E T O is the one you were thinking of, which is funny because it's always pomodoro, but paro is the one that you now forgot. That was the one I was trying to remember. We progressed on. Um, wow. There's there's actually a lot there. Um the first one I I think the first one I want to touch on and we've actually touched on this before not really from a software point of view but from a uh consistency point of view is when you communicate a deadline to your customer that is the ultimate priority and Michael nailed it is like it is a little bit underpromise and overd deliver But the neat thing, the magic that we have in software development is um and this is sometimes tough and I'll talk about that is that we can set our schedule. Usually a customer is going to say how long will it take to get X done? Now, this is an interesting one because Michael and I have been through some of these a couple times is that we will say he, I, whoever developer says it will take, let's say, 10 weeks to get this done. And let's say, you know, $10, dollar a week, 10 weeks. Um, if you're doing a dollar, we need to talk. But the important point is sometimes a customer will say, "Well, what can I get in eight weeks?" And now sometimes the answer, the proper answer is nothing. We cannot do what needs to be done to get you a proper solution in less than the time that we just gave you. So sometimes you're going to need to stick to your guns. Now, the important thing in all this is that we could also say instead of 10 weeks, we could say 12 weeks. And we stick to our guns. And what we're doing is exactly what the airline did is we're saying it's going to take 12 weeks, but we are going to be different from I I'll have to go back. I have a nice little graphic, infographic that's a few years old. Um, but talks about how many software projects fail. Now, I don't know, honestly, I don't know industrywide if those have grown or shrunk in the last few years. There's a part of me that thinks that they have failed in the more often in the last few years, but they are under reportported because there's a lot of like no code and things like that that goes on that have very low expectations and although they still fail to meet those low expectations, they're not considered a failure. So I think it is a huge benefit for us to set a deadline that is a a publish a communicated deadline that is actually further out than what we're going to do because that allows us to underpromise and overd deliver. And if there is an industry that needs it other than maybe like I don't know lawyers and used car salesmen we are right up there and congressmen politicians in general. Okay, I could be like I could be throwing shade all over the place, but we are but we are living in the shade. So, let's not go too crazy with that. Um, communicate it. And this is actually a critical thing because I think we tend to be too afraid, anxious, scared, pick your word, of saying that, hey, we need to move the deadline. So if you get far enough into a project and you realize that the project's deadline that you communicated early on whatever you did is not going to be correct sooner rather than later say hey I missed it this is what up this is the changes that occurred whatever it is because you don't want to just say well we're going to move it back five weeks suck it up doesn't work well with most customers say we're moving it five back five weeks be and be honest. So if you missed something, if you're like, "Hey, we did not include this piece of your application that we realize is critical in our estimates, that will get you a lot further than you guys suck and you didn't tell us enough or whatever it is. I don't know what your other excuses are or just it's magic and you know, the markets or whatever." like be honest with your communication and that will take you a lot further. Michael has something to say. Yeah, you got to be careful with that too because sometimes depending upon your rate, if it's a fixed rate, you have to bite the bullet. You have to eat the cost if you're running late. Now, if you're hourly or if you're week to week, you even have to be careful with that because if you start going off the, you know, if you go longer than expected, they're not going to want to pay. So, you may have to make a decision to complete the project. Hopefully, you're honest enough that you always want to make sure your customer first, but there are times, you know, bad customers. But be besides that, we always want to make sure we're providing the best detail or the best product to our customer. So if you do screw up like Rob just mentioned, you may have to eat the cost. So keep that in mind. Sorry, Rob. Go back. I think No, I think that's actually really important is that sometimes we screw up. It's our mistake. And we talked about this actually in a prior episode. There are points where it's like, okay, I made a mistake. I'm going to eat the cost. But there are also times where you made the mistake. You real you thought that they were going to build a one-story house and you realized they were actually building a two-story house that it's like, hey, there is I'm going to not I'm not going to make money maybe off of this error, but I'm also I can't afford to lose money on this error. It's like look, this is legitimately, you know, I thought we were building a th00andt house. We're building a 3,000t house. you are getting a higher value. Now, we'll talk about that in another episode. We've talked about it. We will talk about it again about like understanding requirements, but they're going to your best your best friend regular constant clear communication. And when you set a deadline, you should be very focused on that deadline. This actually goes back to the most simple ones that we've talked about is like if you start a blog or a podcast and you say, "I'm going to do," let's say you're you have a podcast and you say, "I'm going to produce a podcast every Friday." Come hell or high water, you need to make sure that you put one out every Friday. Now, you can look at us. We have 800 plus episodes and there are maybe singledigit number of episodes that did not go out on time. Half of those were because of like, you know, systemic errors and things like that. So, we're not perfect, but we busted our our little boohinds many times to get that out because that's what is expected. And so you need to do the same thing is so when you set a deadline and this is other than you know the one thing I want you to take out of this is what is it that is required to get from when you are done to actually put it into production with your customer. The other thing is making sure that you are realistic in what can you get done so you don't set a deadline that has you working you know 20our days for weeks and weeks and weeks and instead you're actually doing something realistic. Now it brings us to the challenge and that is really the quintessential part of this is think about a current project that you're on that you're working or a a service that you're providing. First let's start with what is done as far as you're concerned. When do you consider your work complete? And then I want you to step into the shoes of your customer and say what do they consider work complete? Because it may be as simple as you create a product, you drop it in the mail and they receive it in the mail. However, there is something that goes on between like dropping it the mail and they pick it up in the mail. And it may be much more complicated that software delivery. I think we underestimate these days more than we even underestimate testing. And not from a uh amount of time that is in that is needed, but more of a we think it's like it's just a snap and it's done and it's not. And this is from somebody who has done package software, shrink wrap software, commercial, small end, all that kind of stuff is that I know that getting to a product that you can put on your machine and you can run and the customer loves it, but then getting it onto their machine that they can run and they love it. There is a time difference in that and we need to be assured of it. And so the challenge I want to throw out is for you to think of your project, your product, your service. What are the steps literally detailed? What are the steps that are required from when you are complete to when it actually the customer gets to enjoy it and walk through those steps and think about that as you're setting deadlines. I think Michael has something to say, so I'm going to let him throw his little bonus onto this one. Yeah. So, I'm not going to wait for the bonus bonus, but for this, if you're struggling to understand the challenge, Google the tree swing use case. And if you're googling it, then click images and look for the software development image where you see a tree swing. It starts out with, hey, the customer wants this, but at the end, the customer really wants this. It's a tire swing. Try that. You will. That almost totally explains this whole episode. It really does because we have different aspects. But I think it really is is like is we we tend to simplify. We tended to say, "Yeah, I can knock that out." Especially as coders. I'm just going to like own it. And it's it's I could say it's just me, but it is literally every developer I've ever met. That is why project managers are told things like when a developer tells you time, double it or triple it. And I I do it for myself, I triple it. And I'm not always like sometimes I'm still struggling through it. And I am not new. I have done this for a long time. And so I know developers just it is not a science, it is an art just like crafting emails. Send us an email at [email protected]. Leave us feedback. Whether it's wherever you get your podcast, whether it's out on the developer channel on YouTube, whether it is on our we have forums, we have blogs, we have all kinds of stuff that you can leave feedback out on developer.com, out on X, we are at developer, out on the developer page, out on Facebook for those boomers that are out there that actually use Facebook like myself, even though I'm not a boomer. Um, there is just you name it, we are happy to hear from you. And whether it is a challenge you're working through, whether it is feedback or you like or you dislike an episode, we love to hear it because we are here for you. We are here partially for us because we enjoy doing this. But part of the enjoyment is being able to help other developers get better because we when one developer gets better, we all get better. That's just like one of those little like kumbaya moments is that if if you're a developer that I follow behind and you've gotten better, that means when I pick up your code 6 months later, I'm going to say far fewer cuss words when I'm looking through your code and vice versa. That being said, it's time for us to get out there and I don't know, write some code, create some projects, set some deadlines. Go out there and have yourself a great day, a great week, and we will talk to you next time. I'm gonna go like micro bonus because we actually had a lot of bonus before this one. Um, and I'm going to let you throw one in there because I think I threw my bonuses out beforehand. I even threw mine in in the call. Um, but but some additional things to this. So, when setting deadlines, write it out. Flowchart, brainstorm, whiteboards are great, post-it notes, put it out. Put as much as you can on paper somewhere to make sure you have at least okay, we need this here. We need to get here and try to fill in the gaps in between. If you don't if you don't flesh out this road map idea, you're going to have a deadline that makes no sense. You're you're throwing out a number that is ridiculous. Now, with that being said, you could still do that and still be totally off. You could completely under uncover something that nothing was talked about, wasn't underco until you get into a system. Sometimes you don't know what you don't know. Uh, so there's pros and cons to this. So, the other thing I want to throw out as a bonus is don't entirely beat yourself up too much if you did miss something that was there that was not talked about initially. Sometimes it takes multiple conversations to uncover what is under the covers versus what they really what what they do dayto-day. So you could have one company where hey this is what our software does and then you try to replicate it and you find out well yes from a user perspective your software does this but there is so much behind the scenes that our timeline just got blown out 6 months because to give you what you do every day we have to make sure we build all this other stuff that no one knows about until you get under the cover. So, I know I diver diverged on that, but when setting the deadlines, there will be times where you just don't know something or something is missed that will bite you in the ass, but don't let it break down your company. Don't let it break down your project. Take it, adjust, communicate, and be very clear with your customer if things go off the rails. Otherwise, if you don't, you're probably going to be fired. Your company might get blacklisted and you may quit. So, with that being said, there will be times where we make mistakes. We've talked about that. But in situations like this when setting deadlines, there is always that unknown. And you can fret about it or you could just bite the bullet and go for it. But if you do set a deadline and there are unknowns, voice them up front, communicate them along the way, and always keep your customer in the loop. So if you find one of these, you communicate it. It's not a shock. Now, it may be a bit of a shock, but it won't be one of those where, oh, why the hell do I need five? Why do I have to pay you $5,000 more? Um, what? No. always communicate. Overcommunication can be bad, but it's good in this case. So, your thoughts, Rob? I don't know if overcommunication is ever bad. It can be annoying, but I think it is always going to be um taken with a grain of salt. So, I think overcommunication is okay. I do want to say there's a lot I could go a whole episode on that. So, I I I want to go back to the the requirements. my bonus. Um, if you go back, I'm not a huge fan of of project management tools, some of the tools in general, but one of the things that I did find that was very useful in the past and it still exists is Microsoft Project and similar tools where you basically line out the pro the tasks and the the time required and then you can assign resources and it just builds out a calendar for you. So, you just you're assigning tasks and numbers and then you get to the end and it's like boom, this is how long it takes. And I actually have and this will be a bonus. I shoot me an email [email protected]. I have a spreadsheet, super simple spreadsheet. It goes back to I've got I think I've got it in Excel and I've also got it in uh Office Libé or Open Office or one of those. And all it is is really just listing out the tasks like screens and stuff like that. Put an hour number to them. And then it's got a couple of bonus things like testing is always going to take x amount and you can put your percentage but like testing better take you know an extra 10%. Or 15 or 20%. Uh project management documentation some things like that. And it's it's really the value of this spreadsheet is not necessarily in all of the intelligence that I put into it as much of it is it really gives you a starting point to say how do you approach projects and it it separates you in the estimation from the deadline from the completion thought because that is What I think for myself, it has helped me estimate better because I do open up those things a little bit. I'm a little wider. I'm like, "Yeah, it's going to take me four hours to create that page instead of two and some stuff like that." And it adds up to a scary deadline sometimes. But that deadline is probably more realistic than something I do off the top of my head. So, that's my bonus for this time. You want to throw something else in before we wrap this one up? Yeah. So setting deadlines is scary. Meeting deadlines is even scarier. There is a science and trial and error to go from the beginning to the end. If your first project goes off the rails and is horribly bad, don't quit. Take that as a learning experience and try to reset expectations for your next project. Be it take on 20% time to the next one or just be more communicative through the project. It can be frustrating. This is setting deadlines. Deadlines in general are very anxietydriven things. There are reasons why we wait till the last minute to do things because we don't want to do it. We've talked about that before. I don't want to beat that horse dead than it is. But it it's just one of those where this is a topic that touches a lot of different things and it affects people many different ways. Take what we say as a suggestion, run with it, try it. Every situation is different, but there is a core to how these projects go. So, that's kind of my parting thoughts on that one because really, if you listen to the whole podcast and you found that one thing touches something you've done, we've done our jobs. If not, uh, well, go back and listen again because you missed something. I just want to say if you've listened to this whole pad podcast, high five yourself. That is pretty darn impressive. So, we're we set the bar a little bit low this time around, but that's okay. We're having a good time. We really do. I if you don't realize it, this is where our hearts lie is that we really want successful projects for ourselves and for you uh for our industry because like this is how we do it. This is this is really the heart of building better developers is setting expectations and actually exceeding them. Not just meeting them, but exceeding them because we do I believe in you. I believe in all of the people that are part of our projects that we can exceed expectations. We just have to make sure that we're honest with ourselves and with our customers on what those are. And there are so many episodes we could talk about about when it goes wrong and about all the other things, but this one I want to focus on. Set proper expectations, set your deadlines, knock that thing out of the park. Under promise, overd deliver. That is it. That being said, we have gone a little long. We have got another one to do tonight. Uh Meamilia is the just as a product thing. Uh Meamilia Flores. It's a golden tequila. Just a little rocks, a little bit of lemon juice. If you're underage, don't learn Spanish. Uh the rest of you, if you know Spanish and my Spanish sucks, uh dispe or some other hopefully not too terribly offensive use of Spanish. Uh obviously, we've had enough right now. We're going to come back with another episode. We are not done with our season. Building better developers, building drunker developers in this case. Did you have a closing thought and we'll wrap this one up? Yeah, just remember Facebook, Twitter, LinkedIn, developer. You find us there. developer.com. [email protected]. Check us out. Leave us comments. And have a great night, guys. This is awesome. I'm going to stop doing that and let Michael do it. He is You are seeing the handing of the torch right now. Have a good one, guys. We will talk to you next time around. [Music]
Transcript Segments
[Music]
We are recording. We are live.
Um, full
disclosure, been a long day. we have had
some caffeine, but now it is uh cocktail
and wine time. Um, so this may be a
little bit different from what you're
used to. Uh, and if so, hopefully in a
good way. And if it's a complete train
wreck, may you never see it. Uh, welcome
back. We are here developer trying to
figure out what we're going to do this
time around. I'm going to look at some
ideas you threw out here because I was
thinking they were pretty good.
something around self-employed deadlines
or when the project falls behind, how to
recover. Um, that's actually a really
good one. We'll come back to that. Let's
see. Let's see that one. Or it's okay to
take a break when you're stuck on a
problem and the problem will still be
there. That's one we've done a bunch.
So, I think we I like it, but we may
come back to it. How could we do that
with business? That was we we've done a
lot from the other perspective. I I
thought of this from a business
perspective. So, and I think that's your
next one. You said when to take a break.
PTO is not just for employees. I think I
like that one a lot
because my company does not actually
have PTO. We have an open PTO policy.
You take it whenever you want, as much
as you want.
Initially, I did the standard like when
you start out, you get two weeks PTO and
then you get another week of sick leave
and stuff like that. Now, part of it um
this will be bonus material before we
even get into it. Part of it was I had
two employees. My primary employee, my
senior employee that had been there a
couple years was going through cancer
treatments and so was not I knew he was
going to blow out sick and PTO and
didn't want to lose him. And so for many
reasons um happened to be my son. So
we'll just like add that little piece.
Um, so I was like, you know what? I'm
going to change the policy. And part of
it was like for myself when I was the
only employee, I didn't feel I was like,
I'm I'm never going to take that much
PTO anyways and I'm not going to pay it
out and there's just so much involved
with it. I was like, you know what?
Instead of worrying about tracking it,
I'm just going to say we have an open
policy and we'll just like if you don't
get your work done, we're going to have
a discussion. And this has been
I think I'm a year and a half into this
maybe and it has not been abused. Now
granted, I'm still a small company.
They're they're so somebody gets hired
and wants like, oh, I'm going to go work
for them. I'm going to take PTO for 6
months. You will be fired and I will
like change my policy. But for right
now, it's pretty it's it's wide open and
it's worked. But I think that actually
gets into the whole like but you need to
take PTO. I have I have talked to so
many people in the past. I've been that
person at some point. Now, early on, I
got paid overtime. Once once PTO was you
had 80 hours with first place I worked,
you had 80 hours and then once you got
another 80 hours of comp time, you got
paid overtime everything after that. So,
it was awesome. I was starting out and I
was able to like work my way into higher
wages for like two months and then they
cancelled that whole policy which really
ticked me off. But I had a lot of PTO
and what I ended up doing which most
young people do when I went to a new job
I basically got paid for my remaining
PTO. Now some people you don't get paid
so you get forced into it but I think
that's like a really good conversation
to have about that. So I don't think I
don't want to get into spoiler alert
with that. I think I do like
um I want to tweak this first one
something around self-imposed deadlines
or when the project falls behind and how
to recover. I think I want to talk about
setting deadlines. I think let's keep it
like broad like that and see where it
goes because um there's a lot in that.
There's a like some of the stuff I'm
working with right now and and different
projects and stuff like that and how
those things work. So I think that um we
may actually be able to provide some
insight into that. So
these ideas came from Yeah. So, six
fingers, four fingers, two
fingers. This is going to be a fun one,
folks. Buckle up, buttercup. We're going
to have a
ride. Hello and welcome back. We are the
building better developers co podcast.
We are building better developers. We
are also developer. I happen to be Rob
Broadhead, one of the founders of
developer, building better developers.
This season we're building better
businesses. This episode's going to be
I'm just going to be like upfront. This
is not caffeinated. We're on the other
side of the day. So, this may be a
little different. I apologize if this
goes off the rails. I am going to give
you a little bit of a spoiler alert.
We're going to talk about setting
deadlines. So, this is going to be
something that um I don't think we've
actually touched on too often. We've
talked about project plans and stuff
like that, but this is like like the
deadline. It's like this is the finish
line and and defining that and and
sticking to it a little bit as well. So,
little spoiler alert, that's where we're
going to go. First, I want to also
mention because I'm me. I am also the
founder of RB Consulting where we are
all about honestly we're all about you.
Whatever your company is, our approach
is we're going to sit down, we're going
to talk to you, we're going to
understand what your business is. We're
going to figure out what is the recipe
for success for you. This is not like
some recipe you get off of Rachel Ray's
30 minute kind of stuff. This is
specific for your business because we
have found that each business has its
own secret sauce or special sauce,
however you want to look at it. There
are unique things that draw your
customers to you. There are unique
things that you do for your customers.
Now technology happens to be a huge
investment for any business. And so what
we do is we figure out your business, we
talk to you, we understand, we learn and
then we take our experience with
technology in the world that's out there
and we help you through integration,
simplification, automation, innovation,
whether it is buying something off the
shelf, whether it's building a team,
whether it's building custom software,
we help you get there so that we can
provide you a technology roadmap and
plan that is good for today, 6 months
from now, six years from now. We help
you take that technology sprawl that
everybody has to deal with and simplify
it down into something we can put a nice
little pretty bow on and hand over to
you so that you can get the best ROI on
what is other than your employees
probably your biggest single investment.
Good things, bad things. This is
actually funny because in the green room
before we stepped into the show, Michael
and I had a long conversation and it
really is the ultimate of good thing,
bad thing. Uh this is actually also
what's going to be in the newsletter
which I have not finished yet but it
will be out probably by the time this
thing comes out. Um it is a busy season
right now. We are blessed and cursed by
having way more work and things than we
have hours in a day. So the good news is
for me in particular I have got a lot of
work. It is meaningful. These are
projects that are not just like
throwaways and stuff like that. I've got
some things that really matter to my
customers. I'm very happy about that and
I've got a lot of them. The bad thing is
that I have probably too many of them
and so I am getting up early and staying
up late to make these things work. Now,
I guess as a side note to
that, bad news, I am too old to keep
doing this stuff. So, I'm going to
adjust. The good news is is that I am
going to be able to separate myself from
some of these projects to downsize
myself essentially and be able to stay
sane while still providing the kind of
quality that my customers honestly uh
they expect but more honestly they
deserve and what
I strive to give to them. And so this is
one of those things that I think it is
it is something we will probably at some
point talk a little bit more about this
in in one of our episodes is the balance
between and we've we have talked about a
little bit like when you grow too much
and you need to bring other people on.
But there are there are some other
factors that are involved there is like
it has to do more with quality which
Michael loves to talk about. So I'm
going to use that as a segue to toss it
over to him and allow him to introduce
himself. Michael, introduce yourself to
the crowd. Thanks, Ro. Hey everyone, my
name is Michael Malashsh. I'm also one
of the co-founders of developer,
building better developers. I'm also the
founder of a company called Envision QA
where over the years I've spent many
many hours working on different projects
either be it in the trenches writing
code working on testing and I've learned
that if we build software or come at
projects from a tester's point of view
it we can build better more refined
software for our customers. So, my
company's focus is to work with small to
mid-size businesses to help you
understand what the technology is that
you're struggling with with your
business. If you need additional
software or if we need to throw that out
or build something custom, we help you
figure out how to make your software
work for you and make your product a
better solution for your
customer. Good thing, bad
thing. Bad thing. I I'll start with bad
thing. Bad thing is I
am it's good and bad but more bad at the
moment. I have so much work to do to
meet all the demands on me that I have
not been able to spend as much time as I
would like living life.
And we've talked about this in other
podcasts and other episodes. And stress
and anxiety are a burden when it comes
to being overworked or overextended in
what you're trying to do. And I I'm in
that right now. Um, with that being
said, the good side of things, it warmed
up today. We're kind of in that warm
side of spring again. Although this
morning we were freaking 36° again. By
midday we're back in the 70s. Uh I hate
Tennessee weather some days. Throw a
rock. It can be one season every hour.
Who knows? Uh but the good thing is I
took a break this afternoon, walked the
property. So I was worried because we
kind of did have a weird winter that we
lost a whole lot of trees. We've had a
lot of bad weather lately. I I just
decided, let me just take a walk. Walked
around. It was sunny. It was warm. It
was quiet. Well, sort of. The birds were
going wild. Uh we have lots of birds,
very happy birds. Uh we we're down to
two guineies from four.
Uh it it happens on large properties.
Long story short, by the end of the
walk, I sat down on our dock over our
pond. And I just sat there for about 10
minutes, just reset. It was such a nice
day. I kept thinking to myself, "Okay, I
need to go dig a line, run Wi-Fi out."
Of course, I go back to work while I'm
sitting there. But it was a great kind
of reset to realize there is a purpose
to what I'm doing. It's not all about
work. So for those of you watching this,
remember that you know there is a light
at the end of the tunnel. It's not
always a
train and we are doing this for a
reason. It there our lives matter. What
we're doing matters and that's the good
to the bad. Okay, Michael's going to go
back to work
now. I will say that was actually
another good thing is that I was testing
today. Um, I don't know if you were I
think you were on the call because I was
working from my I was using Zoom on my
phone and I was like, I'm going to go
sit out in the sun for a little bit and
test whether I can use my iPad and my
phone to do some basic work. Now, I will
promote even though we get nothing out
of this.
If you have one of the, and I don't know
how far back this goes, if you have one
of the more like the recent generations
of iPad, there is a keyboard and
protector combo with it that has a glide
pad on it. It actually is a full
keyboard plus glide pad, and it works
pretty darn good, as they say around
here in the South. Um, I highly
recommend it. I think it's I don't think
it's cheap. I can't remember how much I
paid because I like got several of these
things at once.
125 bucks. I was gonna say it's like 120
to 200 bucks depending on what you get,
but it's actually from a a tactile point
of view, it is actually a really good
keyboard. Not my favorite keyboard I've
had for an iPad. Uh the one that I wrote
the book on was a was much more like a
tap tap tap. I like a harder like a
more, you know, resistant plastic kind
of keyboard. This is a little more
rubbery, but it actually is really good.
The uh the case in general is awesome.
This will be one of those. Shoot me an
email at [email protected] if you want
more information on it. I would be glad
to share that with you because it's just
really cool. I think it is. I think we
are literally approaching a point where
technology is good enough that we really
can go work like out on the dock at our
pond and stuff like that. And these are
some of the things that we need to do.
But right now, we need to get back to
the the topic because I don't want to
like, you know, scroll into what's the
topic? What was the topic again? Um, I
want to talk about deadlines.
And this
is this is an
interesting psychological kind of topic
in a sense. And I'm going to start it by
why why I said it's psychological is I'm
going to go back to a little story about
um a person in my past that was
habitually late and happened to live in
the same house that I did. And so what
we did over time is uh I would sneak in
and I would set all of the clocks 30
minutes ahead of schedule because this
person happened to be 30 minutes late.
Now, the problem is at one point this
person figured that out and so I ska I
moved the clocks further
ahead and the next thing you know people
would visit our house and go, "Why are
your clocks an hour and a half ahead of
time? What is wrong with my watch?" And
I was like, "No, this is on purpose."
And I would have to say, and it's
probably giving it away. She would also
say, "Yes, it's because we wait till the
last minute sometimes as a family to get
stuff done and to get on the road and to
get like get to wherever we need to be."
Now, I say this
because there is obviously with a
deadline when we set a deadline, there
is the we need to do this by this point
factor of the deadline. It could be
things like um we have to get this done
by this date so that the follow-up
people that are going to you know we
have to get this product done by this
date so that all of the people that
build all the marketing stuff can get it
done so that it can ship in time for
Christmas or whatever it is you know
things like that. There are also
deadlines like we need to get this done
because we need to beat um a change in
some sort of like government requirement
or something like that. It may be
something we need to get this done by a
certain date because then that is the
time that we've told everybody that
we're going to get it done. There's a
lot of reasons and they may be very hard
reasons or very soft reasons. And then
there's also the psychological stuff of
we need to set a deadline of Friday
because we know that if we set it for
Friday, we're not going to be able to
get till it till Monday and Monday is
actually our d, you know, deadline or
something like that. We're always, you
know, x days late or if we don't set
this deadline urgently enough,
everybody's going to
dillydally and then we're going to, you
know, we're not going to we're going to
wait and everybody's going to study the
night before the exam to get it done.
Now, some of that actually is uh built
into the agile approach very much. Some
of that is the agile manifesto. If you
look at some of it and the idea of
delivering sooner rather than later,
they don't say it, but it really it does
sort of imply it and addresses the whole
I'm going to wait till the night before
my project is due to actually get
started on my project. And this back
when it was done, most projects were 12,
18, 24, 36-month projects. I mean, these
were not small. These days, those are
practically unheard of, at least when
they start. I've been a part of a lot of
projects that are like, we're going to
get this done in two months. 24 months
later, we're still working on it because
people just didn't estimate right. So
deadlines, I want to talk about I really
do want to talk about more the the
psychological part of it. I want to go
to what is how do you set a deadline
based on we'll call it the real deadline
because these are some things
that honestly every team is a little
different, every group is a little
different, every personality is a little
different.
So for me, there are deadlines I can set
for myself because I know who I am. I
know what my prop propensities are and
things like that. I know what I'm going
to likely do. And so I know I need to
get this done because if I don't, then
this thing's going to come up and life's
going to interfere and all of these
other things. And I want to just like
give a couple of factors for setting a
deadline. Now, one is this is this the
first one is probably the hardest is
look at the actual
deadline and
then it's called uh contingency planning
and backward scheduling. So, if you have
to have this done by January 1st, what
are the tasks that are required in order
for that to be done by January 1st? Now,
usually when we're building software and
we're providing a service or things like
that, we have a we're not done. When we
get done, when something is code
complete, there are other things that go
on. It may be this thing some people
have heard of. It's really rare. It's
called testing. Uh but there's also
packaging. There's also deployments.
There is training. There is user
acceptance testing. There are a lot of
factors that can go on if it's a this
may age me a little bit but or date me a
little bit but there was a day when
people would build products and they
would have boxes and manuals and things
like that but even now like if you're
going to have a manual even if it is not
physical but a digital manual you have
to provide time for that to be created
for that to be vetted tested validated
and things like that not Oblivion
Oblivion was Like, wow. That was almost
15 years ago. 11-1 111. I will never
forget that. That was when it came out,
right? Or was that Skyrim? Uh, that was
Skyrim was 11-11. For those of you
listening, I did show a box copy of
Oblivion. I'm sorry. So, Oblivion was
actually before that. Wow. Oblivion was
like 03 or something. That is literally
like 20 years old. That is probably an
antique that you just showed us that you
have the box for that regardless of what
a system. Okay, slight sidetrack. Okay,
back to deadlines.
What you need to do and this is actually
the most important exercise of setting a
deadline of setting your deadline versus
the real
deadline is to go through the exercise
of what is
required to happen once I get we'll put
it in air quotes for you as a YouTube
you see it the rest of you it's air
quotes what is done what is code
complete is usually the more complete
the like accurate term when I go from
code complete, what are the tasks that
have to occur to go to this is done
complete shipped or something like that
because I have found too often those
steps are not taken into account and
what you end up doing I'm going to give
you from a visual point of view is like
if this is your deadline so if you
haven't go check us out on YouTube this
is your deadline is your fake deadline
this is your like assumed deadline what
happens is usually you're up here, but
this space here is what is needed in
order for you to actually get to
complete. There's so many things and
this is why testing is tossed aside way
too often is because people get to the
end of a very complex project that
somebody and I'm going to be like
judgmental right now. Some said,
"It's going to take us one month to test
this 18 months of coding, this million
line of code product. They're going to
be able to test it in a week." Not going
to happen. Only if you have the
requirements you
need. That's a whole another road. All
right, we're going to go way out script
on like we're getting a little off.
Um, that's a problem and I think that's
the challenge and that's really my focus
in this if there's nothing else and this
is a little bit of a hint a spoiler to
the the challenge is it's it's not as
much about the deadline. It's as much
about
defining not only the requirements but
actually like fully defining
requirements. what are not only the
requirements to build the product, but
actually to ship the product, to deploy
the product, to dis to train the users
to actually get it in
production. And now I'm going to let you
like mull over that a little bit while I
have a little sip of my drink and
Michael provides your thoughts on all
this because I know you're like you're
at the back end of that. You like you're
the the horse's rear that gets kicked
all the time in the testing world. It's
like, yeah, take that, you know, you
made six weeks of testing scripts. Can
you get those done in a week? So that
sets the table probably really nice for
Angry Michael to step up and talk about
testing. So yeah, so you set the table
really well for kind of defining the
approach to setting deadlines. Now Rob
mentioned agile. He also mentioned
waterfall. If you watch the pre-show,
the the big thing is when you are
building
software, there needs to be some idea of
what it is you're going to build. But at
the end of the day, you need to know
what are you delivering. And somewhere
between the beginning and the end, you
need to lay out a road map of how you're
going to build it, how you're going to
reach those features from concept to
completion. We all run into this. In
fact, we're in the middle of a project
right now that has kind of gone off the
rails multiple times, but we're still
moving forward. That is the beauty of
agile. However, there are benefits to
waterfall 2 where you spend a little
more time at the beginning flushing out
all the requirements. You get all the
requirements defined. You flush out all
the tickets you need and then you start
working. Okay. From a new project
perspective, Waterfall, spending a
little more time at the beginning to do
that may be a better
um better start to the project for
defining the deadlines to defining the
requirements so you know when the
deadline is actually achievable. For an
existing project, yeah, you're you're
already in it. You're in firefighting
mode or you're in maintenance mode or or
feature mode.
So that's a totally different beast. So
there you want to go through those
cycles. You want to go through those
sprints. You want to go through quickly,
make changes, keep things moving, keep
things forward, keeping features going
out.
So Rob mentioned testing and that's my
wheelhouse or has been my wheelhouse for
the last decade but I'm still in all
phases of development which is where I
struggle from a company perspective
coming into a new project I want to
build the perspective uh upfront the
testdriven development approach. So we
need to define or flesh out most of the
user stories before we write
code. There is a difference between user
story and requirement. User story
defines how the users are going to use
the
application at the end of the day. That
is what you need to deliver. Now from
the user story to the setting deadlines
to the deliverable that is the
importance. If you can flush that out it
could be more requirements but if you
can define all the user stories
upfront you will be in a much better
place to say okay we have 150 user
stories.
We
know 80% of these are small features.
They're very quick to knock out, but 20%
of these could include like a data
migration. Data migrations could be
easy. They could be hard. Or you could
be dealing with a 30-year-old system
that is soraic and you are not sure what
you're getting into. It could be nice.
It could be bad. It could be the seventh
layer of hell. Um, which unfortunately
is where we find ourselves sometimes.
Um, so setting deadlines, and I digress,
but setting deadlines is an
art that isn't always perfect. You're
going to get it right, you're going to
get it wrong, and you're going to be so
far out in left field that you might
look for another career. But bear with
it. It is not always perfect. You want
to kind of stick with um what is it?
Perto, not that's the timing thing. Um
the word he's looking for is pomodoro.
Yeah,
but you thinking the 8020 rule. Who? Oh.
Um crap. Dang. You just made me lose
that one. Um but anyway, stick to the
8020.
try to deliver 80% of the project. If
you start out saying, "Okay, I'm going
to set my deadline and I want to meet
80% like meaning this is going to give
us most of the
features." You are setting yourself up
for a better delivery. However, as
you're doing that, you got to remember
you have 20% left. So when you say okay
we can get this 80% done say in six
months you better be tacking on another
two to four months after that for that
20%. That 20% could be one month it
could be eight
months. The reason I say this is there
was a study done years ago with
airlines to improve customer
satisfaction. All airlines had to do was
increase the time of the
flights to make sure that if there were
any delays or any
problems, the flight still made it on
time. But 80% of the time the flight is
early. So they have padded the flight
times to ensure that customer
satisfaction is going to be high because
they're always or in most cases going to
be getting you to your destination
before the time you need to be there.
Now there are always the situations
where you don't meet that deadline. And
if you don't meet that deadline, we've
talked about this in the past as you're
going through the project. If you start
seeing this going off the
rails, make sure you communicate with
your customer at every step of the way.
Make sure you have weekly conversations.
Make sure you have daily conversations.
If things are on fire, if things are not
happy, you did a demo, they're not
happy, make sure you include your
customer as much as you can to ensure
that yes, we are addressing this, we are
touching this, we are ensuring we are on
the right path.
So setting deadlines isn't just about
ensuring that, hey, when I go into this
contract or this proposal, this is when
I'm going to get done. Also, you need to
make sure that you meet that deadline or
that you address any changes to the
deadline as they occur through the whole
process. What are your thoughts on that,
Rob? My first thought is paro principle.
P R P A R E T O is the one you were
thinking of, which is funny because it's
always pomodoro, but paro is the one
that you now forgot. That was the one I
was trying to remember. We progressed
on. Um, wow. There's there's actually a
lot there.
Um the first one I I think the first one
I want to touch on and we've actually
touched on this before not really from a
software point of view but from a uh
consistency point of view is when you
communicate a deadline to your
customer that
is the ultimate priority and Michael
nailed it is like it is a little bit
underpromise and overd deliver But the
neat thing, the magic that we have in
software development is um and this is
sometimes tough and I'll talk about that
is that we can set our schedule. Usually
a customer is going to say how long will
it take to get X done? Now, this is an
interesting one because Michael and I
have been through some of these a couple
times is that we will
say he, I, whoever developer says it
will take, let's say, 10 weeks to get
this done. And let's say, you know, $10,
dollar a week, 10 weeks. Um, if you're
doing a dollar, we need to talk. But the
important point is sometimes a customer
will say, "Well, what can I get in eight
weeks?" And now
sometimes the answer, the proper answer
is nothing. We cannot do what needs to
be done to get you a proper solution in
less than the time that we just gave
you. So sometimes you're going to need
to stick to your guns. Now, the
important thing in all this is that we
could also say instead of 10 weeks, we
could say 12
weeks. And we stick to our guns. And
what we're doing is exactly what the
airline did is we're saying it's going
to take 12 weeks, but we are going to be
different from I I'll have to go back. I
have a nice little graphic, infographic
that's a few years old. Um, but talks
about how many software projects fail.
Now, I don't know, honestly, I don't
know industrywide if those have grown or
shrunk in the last few years. There's a
part of me that thinks that they have
failed in the more often in the last few
years, but they are under reportported
because there's a lot of like no code
and things like that that goes on that
have very low expectations and although
they still fail to meet those low
expectations, they're not considered a
failure.
So I think it is a huge benefit for us
to set a deadline that is a a publish a
communicated deadline that is actually
further out than what we're going to do
because that allows us to underpromise
and overd deliver. And if there is an
industry that needs it other than maybe
like I don't know lawyers and used car
salesmen we are right up there and
congressmen politicians in general.
Okay, I could be like I could be
throwing shade all over the place, but
we are but we are living in the shade.
So, let's not go too crazy with that.
Um, communicate it. And this is actually
a critical thing because I think we tend
to be too afraid, anxious, scared, pick
your word, of saying that, hey, we need
to move the deadline. So if you get far
enough into a project and you realize
that the project's deadline that you
communicated early on whatever you did
is not going to be correct sooner rather
than later say
hey I missed it this is what up this is
the changes that occurred whatever it is
because you don't want to just say well
we're going to move it back five weeks
suck it up doesn't work well with most
customers say we're moving it five back
five weeks be and
be honest. So if you missed something,
if you're like, "Hey, we did not include
this piece of your application that we
realize is critical in our
estimates, that will get you a lot
further
than you guys suck and you didn't tell
us enough or whatever it is. I don't
know what your other excuses are or just
it's magic and you know, the markets or
whatever." like be honest with your
communication and that will take you a
lot further. Michael has something to
say. Yeah, you got to be careful with
that too because sometimes depending
upon your rate, if it's a fixed rate,
you have to bite the bullet. You have to
eat the cost if you're running late.
Now, if you're hourly or if you're week
to week, you even have to be careful
with that because if you start going
off the, you know, if you go longer than
expected, they're not going to want to
pay. So, you may have to make a decision
to complete the project. Hopefully,
you're honest enough that you always
want to make sure your
customer first, but there are times, you
know, bad customers. But be besides
that, we always want to make sure we're
providing the best detail or the best
product to our customer. So if you do
screw up like Rob just mentioned, you
may have to eat the cost. So keep that
in mind. Sorry, Rob. Go back. I think
No, I think that's actually really
important is that sometimes we screw up.
It's our mistake. And we talked about
this actually in a prior episode. There
are points where it's like, okay, I made
a mistake. I'm going to eat the cost.
But there are also times where you made
the mistake. You real you thought that
they were going to build a one-story
house and you realized they were
actually building a two-story house that
it's like, hey, there
is I'm going to not I'm not going to
make money maybe off of this error, but
I'm also I can't afford to lose money on
this error. It's like look, this is
legitimately, you know, I thought we
were building a th00andt house. We're
building a 3,000t house. you are getting
a higher value. Now, we'll talk about
that in another episode. We've talked
about it. We will talk about it again
about like understanding
requirements,
but they're going to your best your best
friend regular constant clear
communication. And when you set a
deadline, you should be very focused on
that deadline. This actually goes back
to the most simple ones that we've
talked about is like if you start a blog
or a podcast and you say, "I'm going to
do," let's say you're you have a podcast
and you say, "I'm going to produce a
podcast every Friday." Come hell or high
water, you need to make sure that you
put one out every Friday. Now, you can
look at us. We have 800 plus episodes
and there are maybe singledigit number
of episodes that did not go out on time.
Half of those were because of like, you
know, systemic errors and things like
that. So, we're not perfect, but we
busted our our little boohinds many
times to get that out
because that's what is expected. And so
you need to do the same thing is so when
you set a
deadline and this is other than you know
the one thing I want you to take out of
this is what is it that is required to
get from when you are done to actually
put it into production with your
customer. The other thing is making sure
that you are realistic in what can you
get done so you don't set a deadline
that has you working you know 20our days
for weeks and weeks and weeks and
instead you're actually doing something
realistic. Now it brings us to the
challenge and that is really the
quintessential part of this is think
about a current project that you're on
that you're working or a a service that
you're providing. First let's start with
what is done as far as you're concerned.
When do you consider your work
complete? And then I want you to step
into the shoes of your customer and say
what do they consider work complete?
Because it may be as simple as you
create a product, you drop it in the
mail and they receive it in the mail.
However, there is something that goes on
between like dropping it the mail and
they pick it up in the mail. And it may
be much more complicated that software
delivery. I think we
underestimate these days more than we
even underestimate testing. And not from
a uh amount of time that is in that is
needed, but more of a we think it's like
it's just a snap and it's done and it's
not. And this is from somebody who has
done package software, shrink wrap
software, commercial, small end, all
that kind of stuff is that I know that
getting to a product that you can put on
your machine and you can run and the
customer loves it, but then getting it
onto their machine that they can run and
they love it. There is a time difference
in that and we need to be assured of it.
And so the challenge I want to throw out
is for you to think of your project,
your product, your
service. What are the steps literally
detailed? What are the steps that are
required from when you are complete to
when it actually the customer gets to
enjoy it and walk through those steps
and think about that as you're setting
deadlines. I think Michael has something
to say, so I'm going to let him throw
his little bonus onto this one. Yeah.
So, I'm not going to wait for the bonus
bonus, but for
this, if you're struggling to understand
the challenge, Google the tree swing use
case. And if you're googling it, then
click images and look for the software
development image where you see a tree
swing. It starts out with, hey, the
customer wants this, but at the end, the
customer really wants this. It's a tire
swing.
Try that. You will. That almost totally
explains this whole
episode. It really does because we have
different aspects.
But I think it really is is like is we
we tend to simplify. We tended to say,
"Yeah, I can knock that
out." Especially as coders. I'm just
going to like own it. And it's it's I
could say it's just me, but it is
literally every developer I've ever met.
That is why project managers are told
things like when a developer tells you
time, double it or triple it. And I I do
it for myself, I triple it. And I'm not
always like sometimes I'm still
struggling through it. And I am not new.
I have done this for a long time. And so
I know developers just it is not a
science, it is an
art just like crafting emails. Send us
an email at
[email protected]. Leave us feedback.
Whether it's wherever you get your
podcast, whether it's out on the
developer channel on YouTube, whether it
is on our we have forums, we have blogs,
we have all kinds of stuff that you can
leave feedback out on developer.com, out
on X, we are at developer, out on the
developer page, out on Facebook for
those boomers that are out there that
actually use Facebook like myself, even
though I'm not a boomer. Um, there is
just you name it, we are happy to hear
from you. And whether it is a challenge
you're working through, whether it is
feedback or you like or you dislike an
episode, we love to hear it because we
are here for you. We are here partially
for us because we enjoy doing this. But
part of the enjoyment is being able to
help other developers get better because
we when one developer gets better, we
all get better. That's just like one of
those little like kumbaya moments is
that if if you're a developer that I
follow behind and you've gotten better,
that means when I pick up your code 6
months later, I'm going to say far fewer
cuss words when I'm looking through your
code and vice
versa. That being said, it's time for us
to get out there and I don't know, write
some code, create some projects, set
some deadlines. Go out there and have
yourself a great day, a great week, and
we will talk to you next time.
I'm gonna go like micro bonus because we
actually had a lot of bonus before this
one. Um, and I'm going to let you throw
one in there because I think I threw my
bonuses out beforehand. I even threw
mine in in the call. Um, but but some
additional things to this. So, when
setting
deadlines, write it out. Flowchart,
brainstorm, whiteboards are great,
post-it notes, put it out. Put as much
as you can on paper somewhere to make
sure you have at least okay, we need
this here. We need to get here and try
to fill in the gaps in
between. If you don't if you don't flesh
out this road map idea, you're going to
have a deadline that makes no sense.
You're you're throwing out a number that
is ridiculous. Now, with that being
said, you could still do that and still
be totally off. You could completely
under uncover something that nothing was
talked about, wasn't underco until you
get into a system. Sometimes you don't
know what you don't know. Uh, so there's
pros and cons to this.
So, the other thing I want to throw out
as a bonus is don't entirely beat
yourself up too much if you did miss
something that was there that was not
talked about
initially. Sometimes it takes multiple
conversations to uncover what is under
the covers versus what they really what
what they do dayto-day. So you could
have one company where hey this is what
our software does and then you try to
replicate it and you find out well yes
from a user perspective your software
does this but there is so much behind
the scenes that our timeline just got
blown out 6 months because to give you
what you do every day we have to make
sure we build all this other stuff that
no one knows about until you get under
the cover. So, I know I diver diverged
on that, but when setting the deadlines,
there will be times where you just don't
know something or something is missed
that will bite you in the ass, but don't
let it break down your company. Don't
let it break down your project. Take it,
adjust,
communicate, and be very clear with your
customer if things go off the rails.
Otherwise, if you don't, you're probably
going to be
fired. Your company might get
blacklisted and you may quit. So, with
that being said, there will be times
where we make mistakes. We've talked
about that. But in situations like this
when setting deadlines, there is always
that unknown. And you can fret about it
or you could just bite the bullet and go
for it. But if you do set a deadline and
there are
unknowns, voice them up front,
communicate them along the way, and
always keep your customer in the loop.
So if you find one of
these, you communicate it. It's not a
shock. Now, it may be a bit of a shock,
but it won't be one of those where, oh,
why the hell do I need five? Why do I
have to pay you $5,000 more? Um, what?
No.
always communicate. Overcommunication
can be bad, but it's good in this case.
So, your thoughts, Rob? I don't know if
overcommunication is ever bad. It can be
annoying, but I think it is always going
to be um taken with a grain of salt. So,
I think overcommunication is okay. I do
want to say there's a lot I could go a
whole episode on that. So, I I I want to
go back
to the the requirements. my bonus. Um,
if you go back, I'm not a huge fan of of
project management
tools, some of the tools in general, but
one of the things that I did find that
was very useful in the past and it still
exists is Microsoft Project and similar
tools where you basically line out the
pro the tasks and the the time required
and then you can assign resources and it
just builds out a calendar for you. So,
you just you're assigning tasks and
numbers and then you get to the end and
it's like boom, this is how long it
takes. And I actually have and this will
be a bonus. I shoot me an email
[email protected]. I have a
spreadsheet, super simple spreadsheet.
It goes back to I've got I think I've
got it in Excel and I've also got it in
uh Office Libé or Open Office or one of
those. And all it is is really
just listing out the tasks like screens
and stuff like
that. Put an hour number to them. And
then it's got a couple of bonus things
like testing is always going to take x
amount and you can put your percentage
but like testing better take you know an
extra 10%. Or 15 or 20%. Uh project
management documentation some things
like that. And it's it's
really the value of this spreadsheet is
not necessarily in all of the
intelligence that I put into it as much
of it is it really gives you a starting
point to say how do you approach
projects and it it separates you in the
estimation from the deadline from the
completion
thought because that is What I think for
myself, it has helped me estimate better
because I do open up those things a
little bit. I'm a little wider. I'm
like, "Yeah, it's going to take me four
hours to create that page instead of two
and some stuff like that." And it adds
up to a scary deadline sometimes. But
that deadline is probably more realistic
than something I do off the top of my
head. So, that's my bonus for this time.
You want to throw something else in
before we wrap this one up? Yeah.
So setting deadlines is scary. Meeting
deadlines is even
scarier. There is a science and trial
and error to go from the beginning to
the end. If your first project goes off
the rails and is horribly
bad, don't quit.
Take that as a learning experience and
try to reset expectations for your next
project. Be it take on 20% time to the
next one or just be more communicative
through the
project. It can be frustrating. This is
setting deadlines. Deadlines in general
are very anxietydriven things. There are
reasons why we wait till the last minute
to do things because we don't want to do
it.
We've talked about that before. I don't
want to beat that horse dead than it is.
But it it's just one of those where this
is a topic that touches a lot of
different things and it affects people
many different
ways. Take what we say as a suggestion,
run with it, try it. Every situation is
different, but there is a core to how
these projects go.
So, that's kind of my parting thoughts
on that one because
really, if you listen to the whole
podcast and you found that one thing
touches something you've
done, we've done our jobs. If not,
uh, well, go back and listen again
because you missed something.
I just want to say if you've listened to
this whole pad podcast, high five
yourself. That is pretty darn
impressive.
So, we're we set the bar a little bit
low this time around, but that's okay.
We're having a good time. We really do.
I if you don't realize it, this is where
our hearts lie is that we really want
successful projects for ourselves and
for you uh for our industry because like
this is how we do it. This is this is
really the heart of building better
developers is setting expectations and
actually exceeding them. Not just
meeting them, but exceeding them because
we do I believe in you. I believe in all
of the people that are part of our
projects that we can exceed
expectations. We just have to make sure
that we're honest with ourselves and
with our customers on what those are.
And there are so many episodes we could
talk about about when it goes wrong and
about all the other things, but this one
I want to focus
on. Set proper expectations, set your
deadlines, knock that thing out of the
park. Under promise, overd deliver. That
is it. That being said, we have gone a
little long. We have got another one to
do
tonight. Uh Meamilia is the just as a
product thing. Uh Meamilia Flores. It's
a golden tequila. Just a little rocks, a
little bit of lemon
juice. If you're
underage, don't learn Spanish. Uh the
rest of you, if you know Spanish and my
Spanish sucks,
uh
dispe or some other hopefully not too
terribly offensive use of Spanish. Uh
obviously, we've had enough right now.
We're going to come back with another
episode. We are not done with our
season. Building better developers,
building drunker developers in this
case. Did you have a closing thought and
we'll wrap this one up? Yeah, just
remember Facebook, Twitter, LinkedIn,
developer. You find us there.
developer.com.
[email protected]. Check us out. Leave
us comments. And have a great night,
guys. This is awesome. I'm going to stop
doing that and let Michael do it. He is
You are seeing the handing of the torch
right now. Have a good one, guys. We
will talk to you next time around.
[Music]