No Compromises | How long is that going to take?

The eternal question that every developer hears: How long is that going to take? Aaron and Joel discuss some ways to frame that question, and how to provide an estimate that will avoid unnecessary disappointment.

00:00 Accurate estimates can be difficult
02:00 Disconnect between a developer and a stakeholder
03:00 How Aaron approaches an estimate
06:05 Pad the estimate? Ranges?
07:38 The importance of open communication
08:12 Translating "hours" into real world time
09:50 Planning not pricing
11:56 Silly bit

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:01):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:16):
As developers, one of the questions we frequently get asked is, "So when will this be ready?" It forces us to try to estimate how long something is going to take, and it's almost a joke among developers how badly we routinely estimate things. This is why we want to talk about it as a topic today because I know, Aaron, you have some insights and some strategies to share on estimating. What is your method to answer that question when it inevitably comes up?

Aaron Saray (00:48):
I think before I get into the techniques I use for doing that, you kind of talked about the method. I have a conversation about what this estimate really means and that we're allowed to change the estimate if the requirements change. I think that one of the things that people forget about is, we give an estimate at the beginning of the project, requirements change, and then at the end we're off of our estimate. Oh yeah, because the estimate was given by a certain set of requirements or some certain guesses, and we got more clarification later. I think that's the first thing I like to talk about with a stakeholder. Is saying, "Based off what I know now, this is what our estimate could be.
However, you should know that if things change and, which they do and I'm here to support you when they do, that the estimate and the timeframe is probably going to change too." I think it's also important as much as I sound a little silly saying that, that you're kind of are positive about it too. Like, "Hey, things are going to change and I'm ready to roll with the changes. But just so you know, when we make those changes, that's going to change this estimate." You know, it's impossible to make changes to what you want and have it be done the same way.

Joel Clermont (01:58):
Those changes never make it take less time like. That's probably a rule of the universe.

Aaron Saray (02:04):
That's true.

Joel Clermont (02:05):
Well, I guess. So this might be one of those classic disconnects between a developer and a business person. Because as a developer, the very word estimate to me carries with it some uncertainty and, it's not a guess, it's calculated, but it's not a fixed bid negotiated contract that there will be penalties for missing. But sometimes the business person hears it like, "Oh, you said three weeks, so I'm going to tell my boss three weeks or my customer three weeks." Now you get yourself in some trouble if it ends up taking four weeks, for example.

Aaron Saray (02:39):
You're right, it is an estimate. I would disagree, I would say it is a guess. It is calculated, but in the end it's a guess. There's no way to know for certain on these things. There's a number of things that can happen that should be calculated within your estimate too. I think that's probably a good segue to how I would calculate an estimate and I'd say, that's a pretty big topic. One of the things they suggest is, if you're doing something like you've done it before, it's roughly going to take the same amount of time. You're like, "Well, I haven't done this before. There's no way I've done this particular task before." I think that's true, but I think after you've been programming for some time you have some ideas of how long things could take, whether or not they're a certain way.
I'll give a really simple example. We're going to make a CRUD type feature. Create, Read, Update, Delete so it has a number of different functionalities. When I hear that, it doesn't really matter, kind of, if it is simple enough, I'm going to say, "Well, that'll take 16 hours." And they'll say, "Well, how did you get to that?" Well, I take the four steps. Create, Read, Update, and Delete, and I just say each one of those is going to take half a day or four hours based off of other times I've done that. You can think about that and you think about something in Laravel like, "Well, Laravel really helps us go really fast." A lot of these things.

Joel Clermont (04:12):
True.

Aaron Saray (04:12):
There's a lot of out-of-the-box tools and you don't have to reinvent the wheel. True, but when you look back at what is all involved in something like this, it does kind of add up to that time and here's why. Let's just say we're on our create form and we know the fields and we go and put those fields in there and we do validation and start building out all this stuff and it's taken a couple hours now. Turns out there's a little bit of layout changes that need to happen, so you make some tweaks there in the blade file. "Oh, by the way, we forgot. We need a delivery line instruction, we need this, we need a phone number now." You have to validate that phone number. Okay, I can add all those things on and by themselves they don't take a lot of time.
But combined over and over and over and extending your unit test and all that kind of stuff, before you know it's four or five or six hours for that thing that you're like, "Well, it should have just been a form field and call and create an eloquent model and we're good to go." I think you, you see that, so that kind of does that. Then, again, it's sort of like an estimate, it's sort of like amalgamation of all the things. Maybe we went over now by six. We're six hours on Create. I'm pretty certain Delete is not going to take four hours.

Joel Clermont (05:33):
Right.

Aaron Saray (05:33):
But maybe it takes a little bit of time for some validation, some logic rules to make sure can we even delete this? What's the policy behind it? Things like that. But maybe it only took two hours, but we have some room now we can take those extra two hours from Create and put it into that area for Delete. Before you know it, we're kind of back on track. That's the way I look at some of these things. Is I look at very simple versions of it, it and try to compare it to another simple version and then say every single step I can think of is about four hours.

Joel Clermont (06:02):
Yeah. One observation on what you've said there. Sometimes a developer might have an internal estimate, but then they kind of pad it because they just account for this. It doesn't sound like that's what you're doing. You're acknowledging like, "No, this really is going to take about four hours each." You're not inflating it to cover yourself. Hey, if it ends up taking a little bit less, great, but based on your experience that four hours kind of per method, if you will, is a reasonable real-world estimate. Is that fair to say?

Aaron Saray (06:36):
Yeah, I think that's true. I think that I just gave a really simple example.

Joel Clermont (06:40):
Sure.

Aaron Saray (06:40):
Obviously, as time goes on for larger projects, I've given ranges, something I learned from a project manager. Actually is you can give your best case estimate, which is what you think it's going to take as a developer. You add on 20% overall for unknowns and that's a probable case. Then you add on basically your original +40% and that's probably more of a worst case, then you can communicate your estimate in those numbers. When someone says, "How long is it going to take?" You say, "Well, here's the three estimates I have set up. I'd like to work on this middle one and I think that this is the one we should communicate but don't be alarmed if we trend towards that worst case, because that's also possible."

Joel Clermont (07:23):
The range also communicates some uncertainty too, which is useful for this if decisions are going to be based off of the estimate you're providing. If they realize, "Oh yeah, this really is a range. There is some uncertainty here that can be factored in."

Aaron Saray (07:38):
I think one of the things I learned from being a dev manager too, is on the flip side when I ask for estimates, I know their estimates but I need my developers and, therefore people listening to this podcast too, we need to have open conversation as soon as possible if you feel something's going wrong. As a manager, I'd rather know sooner than later. It's not a measurement of you're a bad programmer. To me, I would feel it's a measurement of you're a very cognizant, very tuned, a very connected programmer, if you can identify areas of risk sooner than later and say, "Hey, I thought this would take four hours. I'm already six hours in and I feel like it's going to take me another six." I'd like to know that at hour five or six, versus a couple days from now when you've had a couple of those line up.

Joel Clermont (08:27):
Sure.

Aaron Saray (08:27):
Because, like you said, there are communications you might have had with other people or just to know the general risk in general.

Joel Clermont (08:35):
Yeah. The other thought I had as you were kind of talking about hours is generally what you're talking about in terms of the estimates you deliver. Do you ever have to translate? Well, if I say 16 hours, that doesn't literally mean 16 hours from right now. It's based on a certain number of hours per day. Do you find it helpful to maybe talk in terms of a delivery date versus hours? Or is the hours also kind of useful for context?

Aaron Saray (09:04):
I think hours is a good example of as much as I try to preach against this value and cost, as well as effort and then timeline is something separate. Timeline is based off of estimate plus external factors. Those external factors are things like, "I'm asleep, I've gotten sick, I'm waiting on a third party to get back to me.

Joel Clermont (09:31):
Sure, yeah.

Aaron Saray (09:32):
Cloud flare is down for some reason. There's all these different things that affect timeline. So that's a really good question. Estimation is more about cost and effort, and timeline should be an ancillary conversation, but it's not the same.

Joel Clermont (09:49):
You raise a good point. This discussion is really about planning, not about pricing. From a pricing perspective, we both are very against hourly billing, so this is really just about an internal team planning, business internally planning when things can be delivered. The other thing too, we've observed this in ourselves, is some days you're just feeling it, like, you're more productive and other days not so much. It could be like you mentioned, you're sick or something else is going on in your life. Sometimes it's just the way it is, you're not as productive as you can be.
That's a useful thing to factor in too. And being realistic, it's nothing negative about you as a person, it's just the reality of life. Is that some days you'll be more productive than others and it tends to average out. But as developers, we could be really optimistic and like, "Yeah, my best day I cranked out this feature in six hours and so for now on, I'm always going to estimate six hours." But you forget those times where it took 20 hours because of all the different factors, including just your energy level and your focus and other things going on in your life.

Aaron Saray (10:56):
I think I kind of wrap this up with saying that, I think estimation is a tool that we use to advise our stakeholders, but not a tool that we should necessarily use to brag or develop metrics about ourselves.

Joel Clermont (11:12):
Oh, yeah.

Aaron Saray (11:13):
I mean, that's kind of what you're saying is it's an estimation, it's an idea. But it's not a measurement, it's not an exact science. It's not a measurement even of the quality of programmer you are. If you've missed your estimate, don't beat yourself up on that. Have a conversation with your supervisor or stakeholder and talk about it. But I think it's one of the tools to kind of measure, is this project that you're tasked with worth it for the business or stakeholder?

Joel Clermont (11:43):
Good point. If you miss your estimates, you are not alone. You are in good company with most other developers.

Aaron Saray (11:50):
Except for me, I've always hit them or come under. I'm amazing that way.
Maybe this is because I live alone, but I think I'm not the only one who does this. Let me know if you do this and please I really hope you do this. But do you ever find yourself having a conversation or even an argument with someone in your head and just railing into them as if they're there in the conversation?

Joel Clermont (12:22):
Oh, yeah.

Aaron Saray (12:22):
You're like... Not that you're answering yourself, but you're just thinking it through and it's like, "Oh, and if they say this, I'm going to go back with this and I know they're going to say this," and whatever. You find yourself doing that a lot?

Joel Clermont (12:34):
In great detail. And sometimes it's not just future conversations you're thinking of having, but like replaying old conversations. Like, "Oh man, if I just would have said this." I can totally relate to that one.

Aaron Saray (12:46):
I think it's the worst when you might even have one of these conversations and then later on you have to talk to that person. And you have to remember and consider, "Did they actually have that opinion I made come out of their mouth?" Or "Am I mad at them? What's going on here?"

Joel Clermont (13:00):
Yeah, that could be some tricky context. If you think about it too long, it almost becomes a memory. Like, "Did that really happen?"

Aaron Saray (13:07):
Yeah. I'm trying to think, is there a way that I can turn that around into something good? I've really been kind of about that is becoming a better person and looking at things I'm doing and seeing if there's something that I can do good with that. You're a pretty positive person. No?

Joel Clermont (13:25):
Sure, yes. I'm smiling right now. Oh, you're asking me for advice on how to make that more positive?

Aaron Saray (13:33):
Yes.

Joel Clermont (13:34):
Okay. I thought you were going to lay some wisdom on me.

Aaron Saray (13:38):
No, I think we've demonstrated so far when it comes to these conversations, I don't have any of the wisdom.

Joel Clermont (13:45):
Okay. How to use mentally stewing on something as a positive specifically for your relationship with that person? Or, just in general?

Aaron Saray (13:58):
Or maybe how to get yourself out of doing that. I don't know because it can't be healthy, can it?

Joel Clermont (14:05):
I don't know, it's worked for me so far. I feel pretty well adjusted. Like, anything in balance, don't take it too far. You know, Aaron, one thing you could consider is using social media. For example, Twitter is a great place to have arguments in real life and so at least you could get out of your head and argue with a real person on the internet.

Aaron Saray (14:29):
You're looking for more tips on how to be a better Laravel developer?

Joel Clermont (14:33):
Then head over to our website and sign up for our free weekly newsletter. The address is nocompromises.io/tips.