Setting Realistic Expectations In Development

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. It is season 21. It is episode some number. I can't even remember now. We're just chugging along in our episodes, working our way through the season. Trust me. Well, don't trust me because we may go further, but it's probably going to be another one of those like 30-ish episode seasons. But we'll probably end up going into just like a follow up season. It's going to be the same kind of thing because we're we have a lot that we want to discuss. We're getting into the mentor mastermind kind of approach. We're talking about problems that we've seen on a given week. And guess what? We see new problems every day, every week. And these are the kinds of things because we are in the trenches just like you are. We're seeing things that are going to help you out that you probably are seeing as well. And just as part of that, I want to introduce myself because I don't always do that. This is Rob Brodhead. I am a founder here at developer developer also founded RB Consulting, which is my day job. I guess this is my side hustle with that if it's if that's a thing in this case. And so I do I am a software consultant by day. I do specifically I do a lot of like IT assessments. Some people call these things like fractional CTO, CIO, but also we do like full full service. We will build your entire piece of software for you or we'll tell you how to build your software and show you like the best ways to approach that. That's me on the other screen. If you can see this just in the other ear hole, I guess, if this is what you're listening to is Michael Michael, why don't you go and introduce yourself? Hey, everybody. My name is Michael Mollosh. I'm also a co-founder and developer. I also am the founder of Envision QA, where I focus on my company focuses on QA assessments, where we help companies look at their software infrastructures and identify where they're lacking in QA. And we also offer other testing services like unit testing, selenium test, A-B testing. And we also have the discussion with the customers to try and flip the QA model on its head. You know, don't wait till the end of the day to get the QA model on its head. You know, don't wait till the end to do the QA, start the QA process when you talk to the customer. So that's me and welcome. So I want to dive right into this, this little topic, because it is a is one that I think a lot of us, particularly if we come out of a developer type role, technician type role. It's harder for us to do this because there is a level of sales and communication and those things that usually are not attributed to us that are a part of this. Now, the first thing is we have to have our ducks in a row. I think we need to really be realistic. And this is to just us that are developers is that we need to break as much as we can the mold, the hard and fast rule that if a developer tells you it's going to take X amount of hours, multiply it by two, at least. And if you can even get it to multiply by 1.5 instead of two, something that you can bring it down closer to reality, that will help a lot. Because the problem, I think part of the reason there is a I've got a little, you know, infographic somewhere about this. But one of the things is not discussed, I think often enough. The reason why software projects fail or over budget is because the developers. Yeah, sometimes it's because they just didn't understand their requirements. They didn't really discuss it right. That kind of stuff. A lot of times, though, it's because we look at a problem would say I can get that done in an hour. I can crank that sucker out. I could like throw some code, spew some code, run it, build it, debug it, test it, boom, done. And it's like, it's gonna take me an hour. And then you find out that it actually takes you two hours or four hours or eight hours, because we don't think about or we don't factor in things like I had a typo that was like it was a capital C instead of a lowercase c. And it cost me an hour to find that in the code that I was generating. Or I had a configuration issue that blew stuff up. Or I chased down the rabbit hole because I thought my code was broken, but it was actually the API provider was just they had broken their stuff. There's just so many ways software can go wrong that we need to like buffer that in. I know we want to be aggressive. We want to say, hey, if it is, we can say, hey, I can get this done in two hours if if everything's good, if everything's going my way. Spoiler alert, nothing is going to go. It's like that never happens in my entire life. I think I've had like blocks of hours of maybe a day where it's just like, oh, boom, boom, everything fell into place. Everything was awesome. And I do it. And that wasn't just because I had been doing this for a long time. It's just because like I was lucking out. I needed to go buy a lottery ticket. The end of the day, there's just stuff that happens. So we need to be realistic and think about that when we are estimating things. It's like add some of that wiggle room in because the more like more often than not, you're going to find out that wiggle room that you thought you were adding in gets just gobbled up very, very quickly. Thoughts on that? Oh, definitely. So it's really interesting hearing this conversation because, you know, we live this all the time and we had a discussion on this recently where, you know, we're talking about doing a proposal for something. And it's like, well, here's the idea or the pseudo requirements. And being a tester, I take everything at face value. So I take the requirement and I immediately start picking it apart. I have I no longer quickly throw out, oh, it's going to take X, Y hours because you're right. We never really know the full situation. The other thing is, is the requirement even the requirement? So there's been conversations I've had with people where it's like, well, I want this. Okay. What is the user story? What are what is the end result you're looking for and walk you back to that requirement? And a lot of times they can't do that. And the moment that happens, you realize that, okay, so your initial requirement or your initial request for what you want, I'm now going to tack on a week for something that might be eight hours, simply because, sure, I'll write this. But then you're going to turn around and say, okay, I want this. And then you're going to turn around. You want this. And that's the scope creep because the requirements are defined clearly enough to actually estimate the job. The other problem is in their mind, they have one thing that they want and that's what they wrote down. But once they see it, that's not what they want. So they're going to immediately start scope creeping. And that's what you got to be careful of. Right. I mean, we don't want to be in the situation when we say, yeah, an hour. But you've now scope creeped in 40 hours worth of work. It's not worth my time. And that's where I think clarity and communication comes in is that if you're going to be a hard ass about such stuff, or if you're going to be very detail oriented, then you need to be detail oriented. And you need to not just say, hey, you know, this is this could like and sometimes I'll do I'll start with like this could take anywhere between 10 hours in 10 years because what you've given me, we don't have enough information. But what you can do is as you're digging into that and you're asking the questions, you're getting answers is that you can evolve that and work it into ballparks and things like that where you can say, OK, based on what you've said, I think this is where we're going to go. It's going to take X amount or X range, X, Y range of hours. And these are the things that are concerns or these are the things that I don't think either I know we haven't really explored or that I don't think we've explored enough so that you got at least a hey, this thing is sort of known or maybe very well known. And that's awesome. And we'll put an estimate around that. Based on that, we can make assumptions about these other things. But those other things are to be determined. And here's roughly what's going to be because what's going to happen is you want to have a customer coming into this, particularly when you're starting out. When they're working on this project and deciding is it what's going to cost them or what's the value of it and things like that, is give them an idea of what that's going to take. Now, if you've done things like this before and they're thinking this is going to be and it could be that it's like really simple, really small. It's going to be just picking a number like this is going to be a five hundred dollar project potentially with what you said. It's like if it's that simple, great. But then warn them and say, you know what? I've done this 10 different times and nine times out of 10. That thing grew into a fifty thousand dollar project because I don't care who you are. Five hundred dollars is very different from fifty thousand dollars. And those are the things that kill us. And sometimes it is it's like it's going to be double or triple or quadruple. But you need to be able to go into those saying, hey, this is what we're looking at. These are our assumptions and let them know sometimes like if if there are things that you don't know, it's don't be afraid to say, hey, this thing I haven't really looked at or here's the assumptions I'm making. Once those assumptions go out the window, then the estimates are basically void because we built them based on assumptions. And I've I've gotten like every statement of work that I put out there has some level of either questions that are yet to be answered or assumptions that are made or a lot of times both. Because those are the things I'm going to point to if things are going one way or another and say this is where our assumption was and it was wrong or it got changed or it got added to. And these are the questions we had and those answers cost us problems. But we should also be able to say when they answer that question and you suddenly say, oh, that's going to blow this up. Don't try to hide it or obfuscate or anything is just say, hey, we didn't get this answered until now. Now that you're telling me this, this is what I see. And I had this, like I said, this sort of was prompted by a discussion I had with the customer where part of it was I said, look, we're on track right now. I said, what what I'm seeing for and we we'd already adjusted some stuff and I'm like, OK, we're on track. What I see, however, this section that is towards the back end of the track, we haven't really started on. And I think it's going to be OK based on what I'm learning, because I think we've like we're getting over the humps. But that could be a problem. And so it's just a little bit of a like, hey, here's a warning that may be a bigger problem. But I think I've got a it's reasonable to leave it there. And then I and I and I actually even told us like, yeah, we could I could buffer that out more. But I basically told like I'm going to it's sort of like saying this is an aggressive estimate. Yeah, we can probably do it, but it's a you know, we have a 10 percent chance or 20 percent chance or 50, 50 chance of making it. And then this is where we see at least here. Here's what are some of the things we see that could be a bigger could cause more issue. I had another another customer that it basically it totally blew up his his project and what his estimates were, because he won. This is where he came to me. The project, he said, is basically done. It's like 99 percent there. I just need you to drag it across the finish line. And he was basing that on what his developer told him. His developer didn't know squat, apparently, about where it was at. It was like that finishing piece was not 90 percent. Ninety nine percent of the way there. It was there was a lot of work and it was stuff. There was a lot of rework. And so this thing that was going to be 10, 20 hours blew into hundreds of hours. And that's the kind of stuff that, you know, if we've been able to tell him that before, he would have had to like decide, OK, am I going to do this? But also we would have like the whole arrangement would have been very different. It ended up being not what we wanted. We ended up pouring a lot of stuff into that because we're like just we like the guy we want to help him. I've already talked about I'm too nice sometimes. They're a bad boy or whatever. But we want to help him. We love this project. We want to do that. But we ended up throwing a lot of stuff into that. And then he still ended up in a situation where he was going to have to spend because we weren't what they really needed. We weren't going to we were going to be able to we could have like put more into that and made it happen. But it was now going to cost us because we weren't going to charge him. But it's sort of a blessing to us because now somebody else is going to come in. They're going to charge him for that work. And they're probably they're going to find it's like more of that specialist so they can hopefully get that thing done in less time than we would have. So it's like a win win. But this is where you've got to be honest about that stuff. I think all of us are the same way. If we go in and we need to get our car repaired and they give us an estimate of 500 bucks and we're like, hey, got 500 bucks. But OK, I've got to pay that to get my car working. If they come back and it's a five thousand dollar bill, we're going to freak out. We're going to say, wait a minute. I would have sold the car. I would like I would have like said that was it if I had known that was what it was going to cost. And so those are the things that we need to consider when we're putting together these estimates and when we're communicating with our customers. Yeah, so you've touched on quite a few points there. The first. So let me start with the end and kind of work my way back. So being upfront with the cost is one of the biggest things. But sometimes the requirements or what you hear from the customer wasn't clearly defined or it's too loosely defined. For example, I had someone that has an idea for an application and they're like, well, it's basically a VRBO, but for this industry. Well, OK, can you give me any more requirements on that? No, that's basically it. And they're like, well, what, you know, what kind of ideas or costs or things are involved? And so I spent 30 minutes and just kind of worked up very high level, like, you know, here are just some things to think about. And then, you know, I threw a price tag out there that was going to be obscene because you don't have the requirements. There's a lot of discovery that needs to be involved, a lot of hidden things. I mean, they really have no idea what goes into the software. So I think I put it between 50 and one hundred and fifty thousand dollars because, I mean, it was going to be a mobile app, a desktop app. There's going to be e-commerce. I mean, there's so many things. I mean, that number could easily have been doubled. But I was like, here's if you start here, this is what you're looking at. Now, if you refine that and say, OK, what do I need for a proof of concept? And you narrow that down. OK, here you now shrunk the requirements. You've now shrunk the cost because now we can clearly define what it is. So when you're talking about that one customer that came to you and said, oh, yeah, this product's nearly done. This is one of those times where I would have actually said, OK, let's block out 10 hours. We'll bill you for 10 hours. Let's take or even a couple hours. Do a paid consultation to walk through the application with them, their current environment, the current state of things, get a true assessment of what's going on, and then either take the job on at a clear, a more refined estimate of what you're walking into versus kind of going in unknown. So one, basically you're saying, hey, I'll do a paid assessment. I'll do that software assessment for you. Figure out where you're at. Are you being told what it is? Is it really at a state you can get it to where you need to go and maybe even just give them peace of mind? Yes or no. And here's where you're looking. You know, here's what you need to do. And then the other one, as you're going through these requirements or you actually define all the requirements. From a tester's perspective, I look at every ticket as what is the statement of work? What is the requirement based on the requirement? What do I need to do to get this? You know, basically, what is the acceptance criteria? What is it that I need to do to say that this unit of work is complete? What is testable? What is not in scope of this requirement or what is within scope of this requirement? And that also helps you kind of narrow down your budgetary hours. You know, we talked about one proposal we were looking at doing it. You know, I started out with about what, 40 to 60 hours because you gave me a very high level like, oh, here's an idea. Or, you know, here's a statement of work for something like this. I'm going to start high because I have no idea what all the nitpicky pieces are. But then as we started narrowing it down, we got down to what? About three days, maybe four days of work out of that. So that's what you have to consider as you're going through this. Now, where me and Rob differ a little bit is I come at these from a tester's perspective. I come at it from the user's perspective, not so much from the developer's perspective anymore. And that's just from years of writing tests, fighting with requirements, reverse engineering requirements, because there's no documentation for the software that you're working on. And it's like, well, here, make this work. How is it supposed to work? We don't know. And then you're like, oh, wait a minute. OK, so what you want me to do and you have no documentation. Yeah, your budget just got blown because I now have to spend X amount of time essentially learning your application, understanding what you have, because you clearly don't. And then you're expecting me to then build on top of that. So these are a lot of the things and problems you could run into that you have to think about. And there are some forethought you can put into some of these before you even do there, like we've talked about. You know, do like a 30 minute free call and talk through a simple RFP, not a detailed RFP or even a software assessment or QA assessment. You know, these are just some ways to help shrink that. The pricing or your budget for a particular project, if that makes sense. Yeah, and I think you mentioned because this is one that's going to this is like, again, one of those is an ongoing discussion. Is it you mentioned a proof of concept? And I think that's something that very often it is worth it to to push a proof of concept or a minimum viable product is to in a lot of companies. I've seen a lot of customers that are starting to realize this. And it's like, let's get something that is definable, that we can actually like put our arms around and let's get that done and figure out what that costs and what it takes. And dig into that and then we can figure out if we want to go beyond it. Now, I do see like this sort of things I've seen when I've put proposals out. I don't know how many times I've had somebody say, here's what we want. Here's a request. We want this thing. And I've had to send back. I can't give you. I can if it's an hourly rate, I can give them like here's an hourly rate. But they'll say I want to fix bid. And this is what I want. And I'll be like, it's impossible. And it's funny because I don't have that often that they come back to me. So I think a lot of them get burned and because somebody says I can do that for a thousand dollars and they're like, cool, my budget was two thousand. I win. But what happens is they lose because it doesn't get done or gets done for ten thousand dollars or more than that. And I will I will often go to them and say exactly this kind of approach. And it's I've had a few that I have won a project because I was just straight up with them. I said, look, this is I can't give you any kind of ballpark with what you've given. You've given me something that is very minimal. These are just some of the questions that need to be answered. These are some of the things that you need to consider. And then once we can, like I can get answers to those, then I can start putting together an estimate and then we can start thinking about what this is going to take. But again, that's a lot of times what I'll do is I'll say, hey, I'm going to I will I'm instead of bidding, you know, fifty thousand dollars for what you think is a fifty thousand dollar project. I'm going to bid five hundred dollars and I'm going to go spend a few hours and we're going to put together a plan. We're going to put together some requirements or I'm going to spend whatever it is, figure out what it's going to take. And I use I will adjust that based on a lot of times is based on how big their project is. If they say, hey, this is a million dollar project. For ten thousand dollars, I will help you put together that plan. If it's a thousand dollar project, then I may say it's going to be maybe it's only a hundred dollars or something like that. But I'll say, hey, we need the plan first. Sometimes it is like I've only got a thousand dollar budget. I'm like, well, you know what? Just to put the plan together is going to cost you five hundred of that. And so there's no way we're going to hit your budget. So you're going to have to like adjust that. And those are the kinds of things where you get out. Don't be afraid to step into those. And this is where, again, I've gotten burned a couple of times where it's like, hey, this works. This is there. It's solid. Things like that. And you turn around and you're like, no, it's not all these things you said are there. They're not there. You said there was documentation. It's not there. You said they have a bill. No, no, they don't. Or they build it, but they can't build that anywhere but their machine. There's those kinds of things that you it's worth checking that stuff out. And this is where I'm going to pause because I know we're going a little long this time. So I want to wrap this one up and just say, you know, what are some of your horror stories? Feel free to share those with us because we've got plenty and we will continue to talk about them. But if you guys have anything, shoot us an email at info at developer.com. Check us out on the website. You can leave us comments. You can put comments down the show notes. You can see stuff there. All the different places you can connect with us. But we will be back. We're going to continue these discussions because, as you can tell, we have a lot to say about them and we have suffered through a lot of them and continue to do so. So go out there and have yourself a great day, a great week, and we will talk to you next. Thank you for listening to Building Better Developers, the Develop-a-Newer Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Thank you.