Embedded - 402: We Are a Lazy Species

Episode Date: February 18, 2022

Chris Svec of iRobot and Phillip Johnston of Embedded Artistry join Christopher and Elecia to talk about the hows and whys of estimating software schedules.. The article that started the discussion was Agile Otter’s Platitudes of Doom.  You can participate in these sorts of discussions on the Embedded Slack Channel by supporting Embedded on Patreon.  On Phillip’s Embedded Artistry Website you can find a library of courses, hundreds of free articles, and even more member's only content. Their current focus is developing two new courses: Designing Embedded Software for Change and Abstractions and Interfaces. There are also many great posts on planning and estimation.

Welcome to Embedded. I'm Alicia White, alongside Christopher White. I know this is weird, but I'm really excited to be talking about scheduling and planning this week. We have invited Chris Svek and Philip Johnston to join us again to give us their opinions on the subject. I thought we were talking about genres of music and best decades for music. You swindled me. Yeah, there are different show notes for you these days. All right, well, I'll see you later.

Hello and thank you to the show. Thank you to the show. Thank you for... It's time to play the music. It's time to light the show. Thank you. It's time to play the music. It's time to light the lights. Hello, and thank you both for being on the show. Hello, thank you for having us. Hi, Chris Speck, who I will refer to henceforth as Speck, and hello, Philip. How are you? Hello, I'm doing good, and thanks for having me back on the show.

Speck, could you tell us about yourself? Sure. I'm Chris Sweck. I am a longtime embedded software engineer, and currently I manage the embedded software engineering team at iRobot. And Philip, what about you? I'm Philip Johnston. I run embedded artistry with my wife, Rosie. We're a consulting firm and an embedded systems education company. And I'm primarily an embedded software developer, but I've also worked as a project manager, both officially and unofficially. What is an unofficial project manager? Like, is that like you sneak in in the evenings and like do project management when no one's around?

What is that? It's kind of like that. You know, if you're on a small startup team and nobody is trying to rein in the chaos, that's usually when I would just step in and try to put some order in place. Got it. And you said teaching embedded. What's that about? We have a number of courses that we sell, but also for a long time, I've just been trying to take some of the lessons I've learned throughout my career and actually document them and share them with the community. Because I think it's been difficult as a professional embedded systems engineer and software developer to figure out the best way to tackle some of the recurring problems that we find. You know, we're always reinventing the wheel. So just been trying to share what I've learned in hopes that it helps other people, you know, take that and do something even better with it. Embedded Artistry, which is Philip's company, has a great newsletter and a great blog. So just

don't want him to take this part out. Well, thank you. Okay, we want to do lightning round, but instead of it just being short questions and short answers, we want short reply times. So please answer quickly. I don't have the document open. So you're going to have to give me 30 seconds here. It's time to play the music. It's time to lighten the night. I'm the, I'm the editor. I can remove all this stuff. I have, I have great, I've been in your show enough to know that you can cut a lot of stuff out, man. I can cut it all out.

It can be like the, what is it, 432 or whatever. Okay, I'm ready. You want me to go first? Are you ready, Speck and Philip? Yes. Yes. You need to defuse a bomb. Do you cut red, black, green, or blue?

Green. Blue. You're both dead. That was going to happen anyway. VI or EMAX? VI. VI? I don't really like either.

Spaces or tabs? Spaces. Tabs, hardcore. Oh, wow. C or C++? C++? C++. Star Wars or Star Trek?

I'm pretty heavily in the Star Trek camp. I'm going to have to go Star Trek. I'm sorry. Okay, well, that's it. I've had it. How do you pronounce G-I-F? Gif. Gif.

God, this is great. This is great. We are opposites. JPEG or PNG? JPEG? I'm PNG all the way. Mac or PC? Mac.

Mac. Oh, well, see, there we go. Everybody's happy now. Peace in the land. The two of you are on the embedded Patreon Slack group, and you got in a slight disagreement. And like a bunch of grade school students, we made a big circle and watched. And it was great, though there was no name calling. And I think you ended up hugging it out.

Are you sure? Anyway, can you fight for our amusement now? I'd love to. It'd be a great great pleasure i i should say that what happened is that philip posted a a blog post about estimation and i got stuck about a paragraph in on something the person said and i didn't read the rest because i was just like look that this it bothered me and i stopped it right there and i made some comment about it and uh philip said no no no that's not the point that's not the point.

That's not the point at all. And so we kind of went around a little bit there. And eventually we ended up arguing. I at least ended up arguing both sides of like estimates, good idea, bad idea, when you need them, and a few other things. So it was apparently entertaining enough that you wanted us to come on the show and have it out. So, yeah, let's do it. I believe, Philip, you didn't like the idea that software is unable to be estimated. That is true.

It's usually, I guess, positioned as estimating software development tasks, or it's generally impossible, and so we shouldn't bother. And that kind of annoys me because it's a big part of our business practice and the way that we engage with clients. And I think that we do it quite well, having only once missed a deadline that we set, and that by two weeks, which wasn't very far off overall. And so if I feel like I can do a thing well, and it's claimed that it's impossible, there's a mismatch there somewhere. And so Svek, do you think it's a waste of time to try to estimate software schedules? So in reality, first I have to say this, in reality, I think software is estimatable, and it is necessary to do it, even if you don't think you're going to do a very good job. And it is absolutely a skill that you can improve on and both for yourself and for your team.

So that's my actual opinion. I think it's necessary for many, many reasons. I think it's good. But I guess maybe I'll talk a bit about what hung me up on the article. The article, which I... We probably should mention the article and link to it. I don't remember what it was, so maybe make a note to... I have it here.

It's... Platitudes of Doom or something. Yes. Platitudes of Doom from Agile Otter. Tim Odinger's thoughts on software development well the piece that i got hung up with was that in the beginning it says in software development the primary input to today's efficiency is the quality of the code we have written until now if that code is clean bug-free well designed and well organized then today's task will be

reasonably estimable estimatable so that's the biggest. So the premise of that is if code is bug-free, then we can estimate it. And that's where I stopped. That's not fair to Philip's intent for the article. Well, that is absolutely where I stopped saying, like, look, we're not good at estimates. And if you tell me that, that's almost like an excuse, like saying, well, if the code's not bug-free, then I can't even estimate it. Now, maybe that's not what the author intended. But when I read it, I was just like, come on, that's almost like an excuse like saying well if the code's not bug free then i can't even estimate it now maybe that's not what the author intended but when i read it i was just like come on that's ridiculous that is just ridiculous so i did read this but it was a while ago and and as i am want to do i did not prepare for today's podcast um so philip that that paragraph

reads to me as very weird not just for the reason that chris, I know you're not arguing necessarily for the article or anything. I'm just trying to understand. What about software that hasn't been written yet? That, by definition, has very clean inputs because there isn't any. No bugs. No bugs at all. So when I'm estimating software, I don't usually have a pre-existing body of work that I'm building upon all the time. Well, how long is it going to take you to do that driver you're supposed to do?

I don't know how long it's going to take because I've just started reading the data sheet. But I will have an estimate at some point, but it's a bit ineffable. So for the sake of this, would you like me to just say, estimates are stupid, there's no point to just say, estimates are stupid. There's no point in doing that. No, no. Just take that.

No, I'm just saying, for the sake of argument here, should I just take that to start with and then have Philip say, well, I don't think that's true. And then we can just go back and forth and see where it goes. But I think in reality, there's a middle ground. But I think I'd like us to find that middle ground somehow. And yes, Feck, if you're willing, there's a lot of good reasons why people don't estimate and why they find it difficult. If you are willing to play that role, I would appreciate it because we do need to dismantle some of this. And there is validity in the idea that you need to have perfect bug-free code to start? No.

Okay, so what does the rest of the article say before we get into this? Wait, I had terms I need to identify. Oh, go for it. What does ineffable mean? Cannot be effed. Cannot be understood. And Zweck, this one's for you. What is estimable? The word in the article is estimable?

Is that a word? It is a word, but it doesn't mean what he thinks it means. Oh, it doesn't mean is capable of being estimated? No, you pointed out that it actually means capable of being liked. Esteemable.

Which I will take the position, the radical position, that no software is capable of being liked. I think that's just the truth. Computers were a bad idea to begin with. Okay. So we may say estimable, estimatable, but what we mean in either way is estimatable, not whether or not we like the schedule. Okay. So the rest of the article went on to say that things were estimatable? The article I don't think was about estimation at all,

which what I think was where I was frustrated in that particular moment was 12 years ago, he could have had an editor that deleted that entire paragraph, and there would have been nothing lost to the article. In fact, I could argue based on what happened as a result of that, the article would have been better, but that one paragraph struck. The article's purpose was if you think that you're not getting what you want from your software development team because they're not working hard enough, then that's a problem. Because the work that your team can do is probably pretty constant and just wanting them to do more and expecting that they can and, you know, pushing them to do more and more work just to meet some deadline or, you know, for whatever dysfunctional reasons we come up with inside

of our organizations, that doesn't work. And so what's the right way is probably to do less and to pick what you do in a way that what you do provides more value than the stuff that's left undone. I think that was ultimately what the point of the article was aiming at. Okay. And then that just led to the side discussion that we're having now. So, Svek, why is estimating difficult? Estimating is difficult because by definition, you're doing something you haven't done before. And so you, you know, there's the famous, you know, you know what you know, and then you know some of what you don't know.

And then there's plenty of unknowns, unknowns. You don't know what you don't know. And then there's plenty of unknowns, unknowns. You don't know what you don't know. So one of the reasons why estimating is difficult is because you are predicting the future and we all know we're not terribly good at that. Estimating is difficult because frequently you don't know exactly what the thing is that you are trying to estimate, especially in software. There sometimes are not requirements that are very well specified. The person or the group asking for a thing doesn't know exactly what that thing is. And so by definition, if you don't know what you're going to do, it's pretty hard to estimate what it is or how long it will take to get there. Those are kind of two of the more common ways or common reasons why it's tough. So we're not good at it.

And even if we somehow gained skills at it, most of the time, the definition is such that we can't, it's not defined. We can't estimate something that isn't well-defined. Right. And I mean, a very poor or response to that is to say, look, this is tough. We don't actually know. We all know that we don't know exactly what we want to build. So let's just throw up our hands and not give an estimate and it'll be done when it's done. And we'll figure it out along the way. And whoever's asking for a schedule, you know,

go away. Just, you'll get it when you'll get it. Leave me alone. And so that is... It does take a long time to put together an estimate, especially if you're trying to do a good one. Exactly, exactly. And again, I'm playing devil's advocate here.

But yeah, that's time spent on creating a schedule is time that I could have spent building the thing you wanted me to build. So again, leave me alone so I can get to building it faster. Time spent learning to code is time I could have been spending coding. Well, no, I mean, haven't you ever been in a meeting where it's a schedule update and it's just totally useless?

I worked at a place that had a wall of a room that was just the schedule. Every wall was covered in Microsoft Project. Well, I think that's where a lot of the dislike of estimates come from. I mean, I can think of every scheduling meeting I've ever sat in at any company I ever worked in other than my own, where it was just one or two hours, usually at lunch, when you want to be out having lunch with your friends or at the beach or doing something else.

And you're just having somebody pull up a list of tasks that you've never heard of before. And for the first time you're hearing about it, you get a one or two sentence summary of what it is. You've never looked at any code. You're not thinking about the problem and you have to give an estimate. And we just keep doing this in circles around the room until we have a plan for the next two weeks or a month or whatever. And then everybody's surprised at the end of that, that for these problems that nobody put any thought into at all, that they came up with crazy wrong estimates. So of course, if that's your experience, it's like, that's absolutely horrible. And I hate it just as much as everyone else. But there's another experience where I

actually put in a lot of time for my estimates. I thought about it. I thought about when it needed to be done. I broke it into little pieces. And I spent a long, long, long, hideously long amount of time thinking about it. And then when I showed up at the scheduling meeting, they said that was impossible. It was too long. And I was wrong. And they didn't take my estimate, which turned out to be perfectly valid. We just slipped every week until we were at my schedule. And I wasn't just estimating for myself. This wasn't me sandbagging. This was me estimating for a whole team. And we were right on time, according to my estimate.

But they wouldn't take it. My last full-time position, that was exactly why I quit. They set a schedule before they even had a firmware developer or a project manager. So Rosie and I had joined this company together, and we came up with a schedule that we thought was an aggressive schedule. There's a lot of risk involved, but we think we could hit this schedule. They just didn't want to accept it because it was, you know, two months after their target ship date. So I quit because I just wasn't going to do that again. And, you know, looking for the news updates, they shipped two weeks after the schedule that we created, you know, and so it was like, that totally happens, you know, and I think part of

the dysfunction too, you know, maybe that's another symptom is going from we have a schedule and we need to like that estimate, the discussion, I don't think, should be around whether or not that estimate is valid as much as now you have a tool that's shown you that you probably have too much work for whatever time frame that you have. And there's always valid reasons for why we have to ship in September instead of November. And if that's a valid reason and that's not negotiable, then I think having an estimate and seeing the scale of the work in front of you, even if it's wrong, even if it's wrong by 250%, you have something now to discuss and see what other levers you can

pull. What things can you take out? What can be released in a software update? What features were we just really aiming for to try to differentiate ourselves, but they're not really core to the experience? You know, there's a lot of different ways you can manage the estimate is too long versus the time we have available problem. But I constantly, at almost every job I've ever worked, I've been told by management, oh, you engineers, you don't know how to estimate anything. You would take all the time in the world if we didn't give you a lockdown schedule date, which I bristle at every time it happens, but it happens just about every time. And I don't know where engineers got that reputation. At one job, I worked very hard

on an estimate with my colleagues for a product and told the people it would take two years because it was a medical product. It was very complicated. And they hired outside consultants to come in and tell them how long it would actually take. And, of course, they kept getting the answer two years, and they didn't like that. And it took four or five years because they didn't actually start for three years because they kept trying to find a shortcut. But I guess where I'm headed with this is it's one thing to come up with an estimate it's another thing for an estimate to be believed and or to be accepted and your your solution was to quit but that's the extreme solution in a lot of cases people can't always do that is there a

question in here i don't know i've got a i want to i want to go back and make sure i understood what what philip just said um real quick um chris so philip what i'm hearing is that you know what i what i think you said is that we some group comes up with a schedule and sometimes for a very good reason valid business reasons we must launch in September. And, you know, a skilled estimator then comes up with, OK, we can launch everything you want in November. And there's some valid reason that everyone agrees to this is, look, September is it. So it sounds like what you're saying, Philip, is that that point that even if the schedule is wrong, as long as we agree that September is it, then we can start to have a conversation of saying, what scope do we need to cut?

So is it kind of a schedule scope conversation there? Look, if we've got to hit September, that means I can have X, Y, and Z done by September, but not A, B, and C. Well, I'm going to answer your question by stepping back and trying to do a judo move. And you can tell me if I didn't do that adequately. So I think, you know, what's the fundamental problem we're dealing with? It's that we are beings that operate in time and we can't get out of that. And time is a scarce resource that you can't get back. We have other scarce resources for doing what we need to do.

You know, money, hardware, rare earth elements, whatever you pick. We're constrained in a lot of ways. And we're also social beings. So we're working in groups to achieve things. It's like we're not working alone to try to solve problems. And if we are, then who cares about your estimate, really? It's like you don't have anybody to answer to or to coordinate with. Don't worry about estimation. Probably doesn't matter. But given that we're operating in time and we're in groups that are doing things together, and we have a lot of different teams that are trying to synchronize their own work to fit within the, you know, the constrained resources we have and to come together to deliver a product, you need some way to determine what work gets done and whether or not the, you know, we can estimate in different ways.

Whether the estimated cost, the estimated time is worth the, you know, the estimated value that is going to be delivered to our business or to our customers from doing that particular thing. And so sometimes it's that there's a fixed schedule with a good date and we need to figure out what it is. But sometimes it's that we have 10 teams that we need to coordinate to all land, you know, to ship a product. We need our marketing team to have their stuff ready at the same time. We've got to have the hardware ready. We have to be able to manufacture it. We have to have our supply chain in order so all of our parts can get there.

We need to be able to distribute the product. You know, there's just all these different concerns that have to line up. And to do that, you know, we all have to kind of guess at how long our work's going to take and what we can get done in a certain period of time and make our efforts line up in some way. And I think that's the fundamental goal we're always trying to solve when we're working in groups. All right. That was an excellent judo move. I believed everything you said, except for the supply chain part. We all know that part doesn't work. Right. Fair enough. Yeah. Right now you have infinite time to work on your software because you can't ship your hardware i guess backing backing up if i mean i think we started this

thinking oh maybe we could do kind of a debate but it seems like we're we're kind of uh stating about some different things about why estimates are good and like when they're valuable and i think two thoughts come to mind one you need to need to have like the people who are involved here, you know, the quote unquote business people and the quote unquote engineers. There needs to be a level of trust and respect if, you know, a deadline and a schedule are going to be a useful task as opposed to kind of like an offensive task or, you know, a weaponized task or something like that. If, if the business has a schedule and they don't care what you say, and they're not willing to, they're not willing to negotiate, um, you know, what, what scope might go into it. And if they're just like, look, I don't care. Everyone worked 400 hours a day because we have to hit September. It doesn't matter. Like no, no, no better schedule or no better estimating techniques is going to help you there. But fortunately I've mostly been in places where, you know, whether it's the business or the market or marketers or whoever it is that, that needs

the thing or the other people who are depending on the engineering to get the thing done by a certain date, it's usually a pretty healthy, healthy relationship there where, okay, we need it by September. Okay, we can't get it for you by September. Let's sit down. Let's have some trade-off discussions. Let's talk about what we can get done by September. And then can we ship a patch release in October or November? But if we go in supposing like an adversarial relationship between the CEO and the business

development and the engineers, you're kind of hosed from the start. You can't see me, but I'm standing up and cheering over here because I fully agree. And I think that it's interesting that so much of the discussion around estimates is not actually, you know, and I think we're doing it here today as we talk about our experiences and where we see the value, but so much of the discussion of the problem with estimates isn't necessarily around the difficulty in estimating and when it makes sense and when it doesn't, as much as how tied into dysfunctional team activities it is. It's almost like it's a hammer we use to beat other teams with or beat down our own people with. So I fully agree you have to be able to work in a team where trust is present.

But, but, but, but, but, but, but, but. Hang on a second. Software engineers really are bad at estimating things. I mean. Some software engineers are bad at estimating things. Almost all starting software engineers are bad at estimating things. Most software engineers are terrible at software engineering as well when they start. And I, again, I shouldn't be arguing this because I'm not supposed to be arguing the

estimates are stupid, but it is a learnable skill if you focus on learning it. And if you don't, then you're not going to get better at it. And I think on that, to piggyback on that, I think a lot of the problem is how often is there really a feedback loop? You know, it's like if you set up a feedback loop of here's what I'm predicting and you write it down and you do the thing and you compare and then you analyze what you did to try to figure out why your estimate was so wrong and whether you have a fundamental flaw to address or whether it was really a one-off thing that you couldn't have predicted and, you know, okay, just maybe I need to increase my fudge factor next time. You know, like that often isn't there. So if you don't practice a skill, of course, you're not going to be good at it. It's, you know, you didn't come out of the womb

being good at developing software, nor did you come out of the womb being good at estimating how to do software, how long it's going to take you to do software work. It's interesting because I don't see the only software estimation tool that I've ever seen that actually gives you that feedback was FogBugs, which is Fog Creek Software, and they had this feature they added. I'm looking at it on Google here. It's EBS, evidence-based scheduling. And so if you used it correctly, my understanding is that you entered an estimate for all your tasks, and then you entered how long it actually took. And then over

time, you, hopefully the engineer, not just the program manager or product manager, but hopefully you, the engineer would see, oh, I have a tendency to underestimate by 50% these sorts of tasks, but actually I'm pretty close on these other sorts of tasks. So it seems like that kind of feedback is necessary to actually learning how well, you know, how well you do estimate and then hopefully getting better at it going forward. Are there any other tools? Yes. Yes. And I'm, I'm, I hate myself for saying this, but that's, isn't that a big, and I have something

else to follow up with this, but anyway. We all do. Isn't that a big... And I have something else to follow up with this, but anyway. We all do. Isn't that velocity in Scrum? I remember we're doing Agile. Every sprint or whatever, we'd total up the points and see how many points we actually did, and they would keep track of who said what and what points there. And then for the next sprint, we would only do the number of points

that we actually made on average. I mean, it's not down to the level of detail of the kinds of things that uh and i'm not arguing for this it's not down to the level of detail the kinds of tasks take this long on average for this person but it was this team is able to accomplish this many points whatever those meant on average and therefore we should only schedule that many points. That was the goal, right? I have many complicated feelings about Agile. I think the whole, like, you know, seeing how long, well, first of all, the fact that Agile quite dishonestly says that points is not the same as time, when in fact they always are. Like that right there just shoots, shoots any credibility has in the foot. But the, the, uh, let's see the, the time horizon of agile is like one week sprint,

two weeks, three weeks sprint. And so you only get to estimate short things. And I think that is fundamentally different than estimating longer things. And I actually want to go back to something. I'm going to take this a totally different direction real quick, and please edit this out if it doesn't make sense. But when Alicia said in the first place, she said, hang on, I went and I built, I spent good hard time and I built a, what ended up being a correct estimate. And I had to think about it. I had to sit down, I had to spend hours, minutes or minutes and hours actually diving in, breaking up big problems into smaller problems, breaking those smaller problems into even smaller problems,

and then estimating it out. I think fundamentally, human beings do not like expending energy, period. We are a lazy, lazy species, and I am absolutely part of that and so estimating is a very mentally difficult task because build you know build me an embedded bluetooth temperature monitor okay sure that'll take a month okay that like that's all the that's all the energy that my brain wants to use on like i i forget which books i've read but our brain actually doesn't like expending energy because it wants to be efficient. Right.

So exactly. Are you, are you groaning? Well, I'm the, I want to respond to what he said first, because I totally disagree. I,

I've enjoyed, I think of estimating as a critical part of design. If you can't design, then you can't estimate because you don't know what you're building. And so I've always enjoyed the estimation process because I consider it part of the design process. What am I building? Here are the pieces that I'm building. Well, okay, how long are those going to take? What feeds into them? What do I feed into? And not to be, you know, bragging, but every time I've sat down to do that at a company and designed and estimated a long-term project, I've been right.

I actually am going to stop you there because that is a really, really, really good point that is going to come up more later about how estimation and design, um, really overlap. And I want to go back to feedback and learning the skill of estimating. Cool. And the way I got to it was at LeapFrog, where I had to estimate a whole bunch of different toys and how long things would take. They were reasonably well-specified,

and then I also had to enter the hours I spent on each toy. And at the end of the projects, after a couple of years of doing that, I was kind of had my own fudge factor figured out. And the person here who is probably the best at estimating is Philip. And I want to know how he got good at it. How did you get that feedback? He went for a coffee. Beyond that, how do you do it? What is your process? Because you do something that in consulting I find terrifying.

Fixed bid projects. Fixed bid projects. What does Philip do? Because I think we all know on the call, we all know what Philip does, but maybe Philip should explain that. Sure. So something that I practice within my business that is very different from every other software consultancy I've ever known. And people just, you know, sling a lot of insults about this and say it would never work and I'm a fool. But I practice fixed pricing for all of our projects with very rare exceptions for hourly work when it really makes sense. But when it really makes sense is never risk. It's usually

just like, yeah, you can call me whenever you need to to ask me a question. I'll bill you by the hour. So, you know, how we got good at it is just I've been thinking about it for 12 years and getting this feedback continually. Originally with, you know, making estimates for how long things would take because I was asked and writing that down in a paper notebook. And, you know, originally I was working on government projects, so we had to log all of our time spent on each project. And so my timesheet was just a great summary. But, you know, I was already kind of in the habit of tracking how long individual tasks took and what project it was allocated to. And so I kind of had that data to compare to. And just, you know, trying to figure out why I was wrong, I think it always revealed

some obvious things, but that's a different direction we can go in. So this sounds like deliberate practice, which is... Deliberate practice it is. Yeah. So it's a little pop culture kind of a thing. You know, Malcolm Blabell's 10,000 Hours that he popularized. I forget, I think it's some Florida university. He actually kind of came up with a lot of it. But it sounds like you're doing a thing over and over again,

and you get to see pretty concrete measurement of how far off were you. Right. And, you know, when I'm far off, it's always a question of why. I guess before we get back to the business thing, I'll just say why it tends to happen. What I noticed is I have had a consistent tendency to, one, estimate that I would spend eight hours a day working on a given task. And in reality, what I spent on a given task was closer to two hours a day, which is, you know, when you're measuring your time and you see that it's pretty alarming, but the other six hours a day are lunch and meetings and

people stopping by your desk and you went to get coffee. And then there's this urgent issue you really needed to take care of with QA. So you could get that software release out on time. And so it's like, I gave an estimate because I thought I would spend eight hours a day on it and I spent two. And so of course my estimates are wrong. And then there's all these other things that I noticed, like, oh, I'm estimating how long it takes me to write the code to solve a problem. But that's not the time it takes to clean up the code so I can get it ready to actually submit and have it reviewed by my peers. It's not the time I spent testing the code. It's not the time I spent writing the documentation. It's not the time I spent taking the review feedback and, you know, adjusting that,

the implementation based on the feedback and resubmitting it, and then fixing the CI failure that was reported based on my new changes because I didn't test things properly. You know, so I just would habitually miss all of that, which is, you know, if you just estimate how long it's going to take you to write some code and you're not thinking of the 80% of the work around the code that you're not thinking of, it's like, you know, of course you're going to be wrong. And so I just, for myself, I noticed that I had this personal tendency to make these assumptions or to ignore these vast areas where I just, you know, I'm clearly doing work that I'm just not accounting for when I'm thinking of how long it's going to take me to do the work. And I still, you know, I get caught now because I have a partner. So whenever we're making a proposal for a client, you know, we go through what the client wants. We think we have a pretty good idea.

We meet with them until we're sure what the project looks like. We try to limit our scope to three months at a maximum because once you start getting longer timelines, I think chaos and the world and the changes in the environment just dominate. And we break down the tasks. We do the sort of, you know, traditionally what you would think of in estimating. What are the tasks we need to do?

What are those decomposed to? How long do I think it's going to take? And then I have Rosie, who was a project manager, I think for 20 years now, you know, give or take a few years, review my work. And she can always find things that I'm still failing to account for. Like a big one is I'm failing to

account for the time that she's going to spend on the project, you know, or I put in all the time for how long it's going to take me to do the work, but I forgot to put in all the time it's going to take me to talk about the work with the client or to, you know, the necessary time delays I need to account for because the client needs time to get me feedback that I can respond to. So I think it's still, you know, I'm still learning and getting the feedback on the things that I've failed to account for. But I do think part of that practice that's let me get to a point where I feel confident in my estimates is I do get that feedback. And I get often get that feedback early enough that I can adjust my estimate before I actually hand it over to someone.

Is being told that we as engineers are bad at estimating contribute to people not wanting to learn the skill, not wanting to bother or find value in it? Of course, of course. I mean, you like doing things that you are good at. And if you think you are bad at something, you're not going to want to do it. If there's a culture of, you know, if you are fortunate enough to work for, with Philip or Rosie there, you're going to see, look, estimates are possible. You have to sit down and think them through and think through the, you know, the decomposition of problems and estimate, but you're going to see success. and you're going to know that, oh, I'm a new college grad.

I'm not good at estimating today, but it's a skill that I can learn. And here's evidence of it. But on the other hand, if you just listen to the old adage that estimates are wrong, we're bad at it, end of story, then why would you spend your time on it?

You're arguing the wrong side, Svek. Yep, sorry, sorry. Philip is wrong. Philip is wrong. Philip is wrong and his business is out of business and he doesn't realize it. Can I ask Philip a couple of questions and feel free to not respond to these, but I want to understand a little bit better because I am not one of the people saying you're crazy for doing this. I'm actually in awe that you do this. Are there kinds of work that you would be

hesitant to estimate like this, to give a fixed bid for? If I hand you, oh, I need an I squared C driver for this chip, you might be able to say, okay, that's going to be this much. If I said, I need a subsystem for a chip that's brand new, that's never been used by anybody else before, here's their brand new alpha data sheet. Would that also be fixed or would you just estimate that in a different way and make it perhaps a little bit longer? How do you gauge, I guess, the known unknowns and the unknown unknowns in terms of the fixed estimate? So, you know, for everybody listening, I want to make two points. known unknowns and the unknown unknowns in terms of that fixed estimate? So, you know, for everybody listening, I want to make two points. One is I've been doing this a long time. And so I have domain expertise and a certain amount of experience, you know, in very narrow areas, so embedded software development, build systems. You know, there's a couple areas

like that that I feel confident in. Now, if you gave me, to use a different example, if you asked me to estimate how long it would take to write a desktop program to do a thing, I probably can't do that at all because I just don't, you know, I do that as a toy project for myself or something internal, but not to like a professional degree. So there are things that I, because I lack the knowledge, I can't estimate them. But that doesn't mean that somebody on my team can't or somebody I know can't or, you know, another

individual, you know, could probably create a perfectly reasonable estimate. Now to answer your actual question, what I usually do, you know, I have a good sense of when I'm trying to decompose the problem, like where I feel a given task is kind of doing a lot of heavy lifting here, where a given area of development is well defined or not. And if I notice something that there's a lot of risk in, then usually I just try to rearrange the project to address the risk first or to try to get to a point where you could get some clarity on coming up with a better estimate. So for something like there's a brand new chip with an alpha data sheet, well, okay, first thing we need to get samples, and then I need to do a bring up sprint. Now, I brought up a lot of new chips, including brand new silicon. So personally, for something like that, I do have a good sense of like, if it goes well, it's going to take me a certain amount of

time. If it goes poorly, and we have design problems, we're working out. It's like, you know, it's an indeterminate amount of time. And some of that is just communicated. Now, from a business perspective, I have the luxury of saying, maybe this project's not for me. Or just saying, okay, I'm interested in this overall project, but I think that if we're going to write the subsystem that uses this new chip, the first thing we do is get the chip. We do initial bring up, we set some low bar for what that means, and we see how that effort goes before I would commit to doing the actual subsystem development. That's how I would do it. People, I give that proposal to somebody, they could very well say, nah, we don't like that plan,

and go to somebody else. And I think, you know, great, that's fine. So you do, you can do a fixed bid for like a part of the project and then another fixed bid for the next part. Yes. Which is just what I do. I do a fixed bid for every hour. It's always the same. Okay, well, thank you. I do a fixed bid for every hour. It's always the same.

Okay, well, thank you. That makes a lot of sense, actually. So I want to move back to Christopher's point of estimation as part of design. Identifying dependencies and concurrencies. And what else is estimation good for? I mean, if we aren't great at it and we're learning it and we don't have the feedback yet, why do the schedule? Why do the estimations?

I think maybe that's where we should have started in the first place. I think we were all excited to kind of get into it. But yeah, that's an awesome question. So what is the point of an estimate? So there are several points of an estimate. There's several benefits to an estimate. You need, as we discussed already, you need to be able to give some target date for other parts of the business for somebody else to, to be able to get their part of the puzzle ready,

of the thing that you're estimating. And you may not like it, but things have to ship at some point. And there's a lot of coordination and a lot of dependencies that go into that. So that's one point of it. Alicia, I think everyone, it's sort of a trite phrase that, oh, no one has requirements. Requirements aren't real. The requirements aren't good enough. The act of estimating, and this is what Alicia said earlier with her, you know, successful estimating work, the act of estimating forces you to discover more requirements, forces you to break down what something you might be like, yeah, that'll take me about three months or three days, forces you to break it down to smaller bits of work that instead of three months, you're like forces you to break it down to smaller bits of work

that instead of three months, you're like, actually, there's four subtasks in there. Each of them will probably take more like a couple of weeks. So maybe it's more like eight weeks instead of three months. Or, I mean, usually it'll probably go the other way. When you decompose tasks, you usually end up with more work than less work. But those are just the couple of reasons

why you might bother with an estimate or what an estimate is good for that I can come up with. Did I miss any big ones? Well, since you're arguing the wrong side again, maybe we should go to Philip. I don't think you missed anything. I think that was a good list. I do think, you know, in terms of design, if you find that you can't estimate something because it's too unknown, clearly that indicates something that you need to spend more time on to figure out what it's going to look like. I don't know how to argue the other side, Alicia. I'm sorry for that.

Well, it's like you just throw your hands up and say, oh, it's too hard. We're not going to do it. It's like nobody really wants that option either. Actually, I would argue with air. I think, I think a lot of engineers, if they assume estimates too hard, there's no point to it. Look, you've, you've just proven my point. We can't estimate it very well. So why bother? So that is a common attitude. I'm not arguing for it, but maybe I'm supposed to argue for it. Anyway, that's a common attitude. It's like, throw up your hands, forget it. I'm taking. I'm taking my ball and I'm just going to say it's going to cost an indeterminate amount of time and money and you're going to get it when you get it and it's going to cost what it costs. Like that's never going to work regardless of whether or not you're a team lead or in business, you

know? So it's like, that would probably be an argument that you can make and get away with at one level in your career that maybe you're not going to be able to get away with at another level in your career. There's maybe a career maturity there that certainly like 22-year-old me wanted to throw up my hands in disgust and just walk away. 25-year-old me probably did too. But as I became a team lead and a manager and you kind of see and you have respect for the others who need the deadlines and you have sort of respect of the deadline itself.

And yes, it's a good thing to come up with this estimate and having a reasonable estimate. Then yeah, the, the, the argument of I'm going to throw up my hands just kind of goes away. The, I haven't really heard the, the, I haven't really experienced the throwing up the hands over scheduling so much. Everyone produces an estimate whether they want to or not, because you've got to plan your day somehow, right? Even if it's on a micro level, in the back of your head, you're estimating how long everything you do takes. But where I have heard throw up the hands argument quite a lot is, oh, the requirements are always changing. The requirements are always

changing. So we shouldn't gather requirements. The requirements we have, you know, we should treat those as malleable jello. And that really drives me crazy because that does feed into estimating because if you don't know the requirements, you can't really estimate very well. But it also is like a, it's a cop-out to, well, we don't really know what we're building at any given time. And that seems like the pernicious core of a lot of this is, oh, requirements change, so don't bother. It sounds like you don't like Agile. That's well-known.

But how many of us have had T-shirts that they've had to sign committing to a schedule? I have never heard of such a thing. Is that a thing? Well, that happened at a startup I was at. We all got T-shirts, and we had to sign them. Everybody in the company signed them, and the T-shirts had everybody's signature on them with the schedule date on them, which we missed by a year and a half, by the way.

I wish I had that shirt. There are, as pointed out as you go along in your career, this is one of those skills that you need to become more senior. It's part of being a team lead. It's part of architecting and understanding the system and not just your code. And we talked about the end date being a part of the estimation process and decomposing the work always leads to additional requirement definitions. One of the things we haven't talked about is that it also shows the dependencies. I don't love Gantt charts, but understanding when the hardware will get here

is a really important part of understanding when the firmware can be done. Because the firmware isn't going to be done before the hardware gets here. And so identifying these dependencies and milestones and also what two things can be done at the same time. The concurrency. I can start bringing up my command line interface or other things on prototype boards before the final board gets here. And that's concurrent. That's two things happening at once. So I want to add, in addition to defining the requirements and getting an end date, estimation is part of design because it identifies the dependencies and the concurrencies. Amen. I mean, Gantt charts are super useful for showing exactly that. I feel like Gantt charts

are tied in with waterfall. And if you do waterfall, then you must use Microsoft Project, and therefore you must have a Gantt chart as if a Gantt chart is this evil being that means your project is doomed or something like that. There's definitely, I at least feel like there is a negative connotation around them. However, Alicia, yes, like Gantt charts are the only visualization that I know of that shows exactly what you said. There are some bad uses of estimating estimates and that whole process. Svek, since that's what you're arguing for, what are the wrong ways to use estimates? Not to do estimates, but to use them. One-time efforts that are punitive or punishment-driven in nature. So, like, the worst thing you can do is, well, not the worst,

a bad thing you can do is come up with an estimate at the beginning of a project, especially a longer project. And, you know, the engineering team spends a reasonable amount of time, comes up with a good faith estimate. They, you know, present it to the stakeholders, whoever's going to kind of need to need their dependencies and says, okay, we're going to be done, we think, in September. And here's what we know. Here's what we think we're going to build. Go. Then no one talks about the schedule ever again, other than, are you done yet? Is it September? Are you done? Are you done? And no one takes any changes into scope or, you know, new discoveries are made, good things happen, bad things happen. No one revisits the schedule. And instead it's treated

like 10 commandments, you know, chiseled in stone. And the engineering team, their feet are held to the fire saying, look, you said September, and we don't care that everything has changed. And this new alpha chip that we forced you to use has a million bugs that, you know, we have to wait for another tape out of another silicon rev to get through. I don't care. You all are in trouble because you didn't hit your deadline. So those are some terrible, terrible uses of estimates. Do you have anything to add, Philip?

No. Having lived through it, I'm just kind of shaking here in the corner with a little bit of PTSD. There's also the opposite of what Speck said, where you don't touch them. There's also the demanding an update to estimates every week or every day when you just can't. It's hard. They're different skills. And it's hard to go from I'm coding and getting things done to I'm thinking about the whole system. Yeah, I agree that doing estimates too often is problematic. I mean, it's sort of, you know, having an idea of what you need to use your estimates for, I think, is important. You can never update them, which probably happens more than it should. You can continually ask, when's it going to be done?

When's it going to be done? I need a new estimate. But I do think that both of those kind of hint at something that is important about estimates is there is an unknown right cadence for the fact that you do need to regularly reevaluate your estimates and update them based on what's changed. And, you know, if the estimates are wrong and your schedule is based on estimates, at some point you do need to look and see, you know, okay, here's where we're at. Here's where we thought we were going to be, the problems we had. What has to change as a result of this? I do think that has to happen.

And you could definitely fall on either side of that, of doing that update too much. And now you have somebody whose full-time job is to bug everybody to make sure that every day the Gantt chart is perfectly up to date and printed out on a plotter and hung on the wall so the CEO can see that, you know, I've definitely been a part of that kind of thing. So, Philip, how do you set expectations with your clients? You know, obviously they know they're coming to you. So, you know, do you tell them, look, this is fixed bid.

I'm going to give you about three months worth of visibility. We'll do some endpoints there. And like, how do you set expectations with them? So three months is just my limit. It's often that somebody comes to me and what they need done doesn't necessarily take three months. But I do just start off saying that, you know, we like to work on a fixed bid so that I provide you with a total cost of what it's going to cost. And that's the cost and a schedule that's, and I do say an estimated schedule. So, you know, it's like, I might think something's going to take me 21 business days and I'm going to say, here's my start date. Here's my estimated completion date. But I do make it clear that, you know, I'm going to communicate early and often if I run into something that's going to throw that off. Now, being fixed price, the trick is, you know, I can't

go ask for more money, right? So I have to be reasonably sure about what I'm doing to some degree to take the risk that, you know, I'm going to run into some unknown bug and it's going to reduce my profit on a given project, but not, you know, bankrupt me or taking out loans or taking out other work so I can pay the bills because I'm having to do something for a client that I didn't anticipate. But I do think, you know, where we get in trouble is things go wrong and then we don't communicate that often enough. And so I try to not do that. I try to, you know, at least once a week give a picture of where I'm at, the work I've done, whether or not, you know, we think things are going to take longer or, you know, we've been making good progress or we might even end up ahead of schedule.

So, just a regular communication pattern is my solution to that. Do people get angry when you come in ahead of schedule and they feel like they've overpaid? No, never. Good. I think, and that was part of what inspired it is I had a client early on and they had some exploratory work for me and they had pitched it that way and it was hourly. So it was just kind of, you know, whenever I did some work and whenever they had time to review what I had done. And then one day I get

this email and they're asking like when it's going to be wrapped up because the project's dragging on too long, which is, you know, funny because it was an exploratory project from their side. So I have a call with the CEO and he tells me that he would have rather have had all the work I did done in a week for, you know, 10x the money just to have it done in a week. And I was like, OK, well, if that's how you're looking at it from the CEO's perspective, that, you know, the shorter time to get the feedback is worth the higher cost. That sort of motivated me to start exploring this. Well, maybe I can just dedicate myself to one project and focus on getting it done as fast as possible in a bounded time that somebody can depend on and schedule around. And, you know, maybe there's some upside there for me if I can pull that off. And since I've taken that model and, you know, nobody's complained if I get done sooner and they paid a certain amount of money. People have complained on the hourly end where

they're like, you know, we told them that, you know, we had an estimate of whatever, but then they just now they're paying hourly and they don't like the bill because, again, from their perspective, it's dragging on or whatever other thing that might be thrown at you. None of that's happened since we had fixed price work, which I'm very surprised by and grateful for. Do you have to deal with code bases that you didn't make? Yeah, I think most of them. I mean, I find myself helping clients solve other bugs. And so I can't imagine doing fixed-bit because it can be quite the time sink to teach a new engineer how to do something

or to solve the horrendous memory bug they've created. Sounds like you just don't take those kinds of things, Philip. You focus on one area and that's what it is. I do take those kinds of things but i don't necessarily structure it maybe in the way that's you know like we're gonna fix this bug um and and that this is the cost for fixing that bug you know if i'm helping somebody's team do it it might be like well i'm gonna give you two weeks of my time and here's what that looks like and here's the price for that and you know we just see what we can get done in two weeks of that time and we

reevaluate. Or it might be that I'm going to give you, you know, 10 joint debugging sessions of four hours in length for a certain price. So there might be times that I do something like that, where it is a little more nebulous in terms of like solving a problem or coaching a person or even just refactoring something to make it a little easier to work with. But you're right that it's hard to, you know, the nature of debugging is that if you knew what it would take to solve the bug, you wouldn't have to pay somebody to do it, right? And you wouldn't need an estimate. You would just fix the bug. So, those are sort of indeterminate problems that are impossible to estimate to some degree because it's like once you've figured out the problem, you could then estimate the time to the fix. But the time it takes to figure out the problem itself is indeterminate.

Well, half the time a fix is like a one-line thing. Totally. And you're just like, how did this ever work? And it's trivial to fix, but it's impossible to find. I imagine you have enough experience. You don't create those for yourself very often. But that is an experience thing. And I have created them for myself. So, how do you deal with the fixed bid and the...

He's explained it already. I know, I know, but it's just so mind-boggling. Okay, how about this? And sometimes he's wrong. I don't think he'd say he's right every time. In fact, Chris has helped me when I was wrong. That was how wrong and forlorn I was that I called Chris one day and I was like, I just need somebody to sanity check my thinking. I didn't help at all.

Are you saying that's how bad off you were you had to call Chris? Yeah, that's exactly what he said. He wasn't involved at all. I offered him zero actual help, if I recall correctly. And this particular problem was frustrating because I had written all of the code in the target time frame. And it was also like a save the sinking ship kind of project to begin with. And the real gate was the fact that the company that sold the chip didn't actually understand the chip because they had acquired the chip through an acquisition. And then the team that had designed the chip was either checked out

or the remaining designers were in Europe, but had worked on other projects in the intervening years. And so didn't really have a good memory. So, you know, and that it was like, it was unknown if there was ever even going to be a solution, you know, and it was just luck. It was truly luck that one day I decided to flip one bit and we noticed that there was, you know, we're suddenly receiving radio traffic when we weren't able to before. But, you know, that was, yeah, I don't have a good answer. Sometimes you just suffer, I think. The nature of the work is that, and I think this is true of most, most projects when they get derailed, they're derailed from like one major issue that takes an indeterminate amount of time to solve. And nobody has any line of sight for how it will be solved, but, you know, solving it

is key to the actual project being completed. And, um, I guess the goal is as much as possible to avoid those, but, you know, sometimes they do happen. And, you know, for a fixed price bid, then, yeah, you take your loss, you lose your profit. And, you know, it's hopefully you still aren't you're not like working for free and getting behind on your bills because you're going that hard on it. And, you know, maybe if you get into that situation, like, here's the truth. I went to the client in that situation. I was like, look, we need to figure something out because it's like, this could go on for months. And, you know, we estimated this project on a, I forget, but maybe

a four week timeframe, you know, and it's like, here we are on month four. It's like, you know, I don't want to give up, but I do need some kind of solution here for at least keeping me afloat a little bit. So that happens. And I think, again, it's just part of the, you know, you have to have the hard conversations and sometimes they don't go the way you want and they're very uncomfortable. That's, you know, I don't think that's any different than the hourly work. It's like, what, I'm just going to bill these guys for a bunch of hours and not give them anything to show for it. And they're going to be just as happy as me coming to them and saying, I need more money. It's like, I don't see that either playing out very, very nicely. It's funny. I've done a couple of the

impossible bugs lately. And I don't, I can't say this out loud, I don't usually end up charging for them. Right. Excuse me, what? It only takes a couple of hours. Or I do a code review, and it doesn't take long enough to set up all the legal stuff. And yet I can't have my coffee maker. That's a marital thing. Fixing one impossible bug would have paid for it. It's true and so I have thought well maybe I should be like

offering the service of being the rubber duck and talking through and there should be a price for that but while I know some of the people I've worked with would have offered a decent amount of money

I just I don't know how to charge that's that's charging for experience instead of time i'm gonna flip us around a little bit uh because i've gotten totally off it's fact you you you work with contract people what is it like from the other end what are your expectations i actually um first all, I just want to say that I think your coffee maker issue is esteemable. I think it's esteemable. I think that's the real problem. But I actually want to flip it around.

You can't flip. We've already flipped. Now you flip it around. We're back where we were. It's a three-sided coin. It's a six-sided die. So the three of you are contracts right so you work on short-term or long-term contracts with companies and my whole career has been inside companies right so i've been in iRobot for almost nine years now and so when i make estimates i make

estimates on a bunch of projects i work with a bunch of people but then we keep working together over and over for eight you know eight, eight plus years. Right. So there's a different, a different type of relationship. There's a long-term relationship that can be built up there. And so, you know, I'm, I've probably worked on 20 different projects over the last couple of years with a bunch of different people. And the good thing is that, you know, some of these projects are short little things and some of them are six months or even a year, a year and a half long projects. And the good thing is that there is, everyone has kind of the same idea of what a schedule is, of what an estimate is. It's like, Hey, we want to do this new thing, software team, the EE team, whatever, we're going to go off.

We're going to sit together. We're going to come up with a schedule, give us a couple of weeks. We'll come up with a schedule. We say, okay, we think, you know, we are 75% certain that we will be able to get done by September. And, you know, here's, we think we have a milestone one in April and we have milestone two in like July. And then we think we'll be done in September. And, you know, here, here's the big risks. We think risk one is this chip. We think risk two is this motor. And then risk three is some process or whatever it is. And then we have this conversation with the business, with the product person. And it's all like, there's a lot of, there's a lot of empathy going on here. I understand what they need to hear to get their stuff done by then. And they hopefully understand

what I think the risks are and what I think, you know, and I say, you know what, if I can get a third person working on this, then I can burn down that risk sooner. And they say, well, but then we'd have to take that person off this other project that needs a higher priority than this project. So, you know, we have the conversation than a month or two in because there is a long-term relationship here. It's very easy to be like, all right, we do our monthly project review and okay, these two things went sideways. And so, you know, unexpected things came up. So September is not doable unless we cut X, Y, Z, otherwise it's November. And so you can have that conversation and you sort of are in each other's heads and each other's worlds, and you're all in the same team, literally and figuratively. And that's how a good estimate is used, how a good schedule is

used, and how a good team works together with that. I've never been in a company long enough for that to develop. I've had some good teams that that's worked with. I've had good teams, but they weren't due to, they were serendipitous. It wasn't due to long-term. Empathy? Sure. I had to bring that word out. I'm contextually required to use that word on this podcast. I think cows has to be said by you as well.

Cows? Excellent. Philip, you said you don't schedule past three months, which is where chaos starts becoming too big of a factor. What do you decompose your tasks into? What is the largest task on your item list allowed to be? Are we talking personally or for consulting clients? Because I think I handle those differently. For consulting clients, I mean, not that you necessarily tell the client, but do you have a week for I2C driver or do you break it down to I2C driver, how hookup into multiple smaller day-long projects?

I think it depends on my comfort with the project. I would say for things like I2C driver, I would probably make that, you know, just its own thing and know all the associated tasks that go on with that. And usually things like that, I'm probably going to estimate in hours because, you know, that just is the currency of the business to some degree. But there might be, you know, for things that I'm not as confident in or just, you know,

I haven't done them as many times, I will break them down into the finer grain steps of whatever I see it as is like, I'm going to talk to this thing with my Aardvark adapter, and then I'm going to get a driver written using the vendor's driver. And then I'm going to get that imported into the system. You know, I might have a fine list of the steps I'm going to go through. And usually that's just for me to have a plan to follow and, you know, I guess as a checklist in some sense and just to make sure that I really understand what I'm going to be doing. Because I think if I left everything big and vague and high level, then again, it becomes easy to miss some fundamental task that was really going to take up 80% of the time and that I just didn't even write down. So to restate that, for things that I'm very comfortable in, I tend to leave those at a very high level. And the areas where I personally perceive more risk or more uncertainty, those I

tend to decompose into smaller tasks. But I don't necessarily do that based on time. It's like I'm pretty sure I keep everything in hours that I write down. I've been told that if you, if you think it's going to take longer than two days, you need to break it down because you don't know what is inside that box. Do you have any rules of thumb like that? You can say no. Yeah.

Well, I'm just thinking, I don't think that I have any rules along that line. Usually it's in the opposite direction. Like, ah, if you think it's going to take two days, it's probably going to take four. But I don't think I'm the, the breaking it down for me. It's all about what I see as the risk rather than like, you know, I'm making estimates for myself and for my clients. So I'm not trying to, to, you know, make up a number to get out of something. So I'm not particularly looking for, like, you know, if you're rating something and you pick a seven, it's like, nope,

seven's not allowed for, for my own estimates. I don't have that rule. Yeah. Working, working with, you know, having, having projects where, you know, we have five, six software engineers a couple electrical engineers and a bigger team working on it if people if only one person understands a particular area and they come back and they say with that i'll take about two weeks i sometimes might kind of dig in and if they've done something very similar before and they say two weeks, then I might just let it go. If it's kind of new and sometimes you can kind of tell that two weeks is sort of a swag answer and it's kind of like, all right, let's figure out, let's break it down some, not because it's like, oh, I don't trust your estimate, but because maybe we all haven't actually thought through

exactly what goes into doing that thing. if your off-the-cuff response is two weeks and we all know we haven't really done something like that before so there's i think i think it's kind of like what you said it's the risk element but when you start dealing with other people then suddenly you have to remember you know who's if someone's done motor drivers since they were seven years old and you know they can write them in their sleep then yeah yeah when when someone tells me two weeks she she'll nail it because she's done this a million times. But if it's newer, then there's more risk involved. Well, I think that goes back to just when I was working within companies and not on my own,

a lot of the scheduling conversations were like, okay, you just heard about a problem for the first time and you have an estimate for how long it's going to take from a two-sentence summary without looking at code or really even reading the issue report to see what was involved. It's almost like if an estimate is too off the cuff, it's suspect. And maybe two weeks is something that some people will say, but I just think that there's like, I don't know, maybe there's a glint in somebody's eyes that shows that they didn't really think about the problem and they're just giving you an answer. Yeah. I mean, I've definitely been

in a situation when our executive VP of engineering, some, some topic comes up and I'm in the executive team meeting and they're like, all right, oh my goodness, we have to fix something or we have to do something. How long is that going to take? And the first thing I say is, I don't know. And the team, the team will go back and in a week we will have a more intelligent schedule for you. And then if pressed, if then you can start saying, look, order of magnitude, this is a six month project, or this is a three month project. You know, that could mean two months. That could mean six months. And you know, you're, you know, that could mean two months. That could mean six months. And you know, you're, you're, you're again, being very over communicative here

saying, look, if you're pressing me for a number today, I'm going to give you a number and I'm not sandbagging. I'm not, you know, I'm not, I'm not, you know, going to tell you it's going to be 10 years for something that I actually think will cost, will take six months. But I think this is six months plus or minus, but that plus or minus is another six months because I don't know enough now. And then you come back and a week later, you have a more detailed estimate because you've actually been able to spend the hard time

thinking about it and getting whatever details you want. Philip, when you and Spec were discussing this in Slack, you had an analogy that really kind of hit me. When people talk about software is not estimatable, you brought up travel time. Could you describe that again? Yeah. So, I think it's a great analogy just because it's something that we all do so freely. And we don't even think twice about the fact that we estimate travel time. It's nothing to, you know, you're going to meet up with a friend somewhere and, you know, you're leaving.

I'll be there in 20 minutes. You know, that's nothing. But along the way, there's any number of things that can happen to you that throw that estimate off. You could get into a car accident. You could get stuck behind a truck that jackknifed on the highway. A snowstorm could come out of nowhere and get you stuck on the interstate for three days. There's all these freak events that can happen that can throw your estimation off. But we don't then react to that and say,

it's impossible to estimate travel time. It's like, yeah, sometimes we're right. We even tend to have the same kind of biases where it's, you know, if you're estimating how long it takes you to go somewhere that you go frequently or somewhere that's close to home, you're going to tend to underestimate the time it takes you to get there. And if you don't know how long it takes to get to somewhere, it's not like you throw your hands up and say, I have no idea how it's going to, how long it's going to take me to get to this new place. You're going to ask somebody who knows. You're going to look at a map and calculate it manually.

You're going to go to Google Maps or Apple Maps or any other mapping service and see what their estimate is. They might even give you environmental factors that you're not aware of, like what the current traffic conditions are, what they, you know, what the conditions are if you leave at different times. And so we have all these ways when we travel that we can, you know, we seem to be able to deal with the ambiguity and the risk of having our estimates be wrong, but we don't let that cloud our, you know, our willingness to make them and to use those to plan our days and figure out when we need to leave. And maybe somebody is habitually late and you know that you have to account for that, right? We even adjust for other people's tendencies with travel time. This person always shows up 20 minutes late, so you tell them that you're meeting 20 minutes earlier than you are,

whatever it might be. But I think when we have these same kinds of scenarios in software, we just don't treat it in the same way we do with travel time. So, you know, if you don't know how to, if you've never done something before, it's not that that thing is not able to be estimated. It's not able to be estimated by you. There are other people who are, who've done it, who have a lot of experience with it that can be consulted, you know, within a company, it's sort of, it's nice because you have a team and the odds are good that the skills on the team are distributed pretty, I don't want to say evenly. Distributed unevenly? Fair enough. Distributed unevenly. Like we're all good at different things and we have different experiences. And, you know, we can consult other people when making our estimates to get feedback on what we're missing, what we're not thinking of, how other people have done it in

the past. And so I think for that reason, I really like to think about travel and software estimation as being quite similar to each other. I'm glad you brought up the people who habitually get it wrong and how other people make allowances for them. And, you know, there are people who, if you're not five minutes early, you're late. There are all kinds, and there are all the little things. You mentioned the catastrophic problems, but there's just hitting all the red lights. Hitting all the red lights. Which only makes you a little bit late, but if you are going for a job offer or job interview that's important i i love that analogy because i think you take it one step further and you're making that estimate i mean maybe you make that estimate because you just like to know how long it takes to get to

the grocery store and you're trying to beat your personal best or something like that but you know if it's hey philip you let's, let's meet at the restaurant, Philip, I'll meet you there at two o'clock. Like you are, you know, you are, you are the product, the product owner or the business, you know, you are the other part of the, of the estimate there. And it's important that I estimate my own travel time so that we get there at about the same time. So you're not sitting there for 20 minutes while I'm stuck in traffic because I left the house too late. So I think that analogy goes even further. I like it. I want to pose a couple of things to both of you and see how you react to them. One of them goes back to software engineers are terrible at estimating, therefore we should never

estimate. I think even if software engineers are terrible, we should still do estimates and try to schedule things because most of the time an inaccurate estimate is better than no estimate at all. Respond, Chris Feck. I agree. I think that an estimate is better than no estimate. You are absolutely right. And the only way you get better is by estimating and learning from it. So I totally agree. Now, I'm going to push back on this a little.

Are there, should we estimate everything? Like, are there tasks or sets of work that we think shouldn't be estimated or, you know? Bathroom breaks? Yeah, I think where you're headed was like, is this a research project with, with, with no visibility? Is that worth estimating? done in a sprint is even worth that amount of effort. You know, so I have a hard time because I am very pro-estimates, but I'm also very anti-estimates in some ways where like, I do think that the, you know, it's an expense to make an estimate and good business is not just increasing expenses blindly. You know, we want to make sure that our expenses are at the appropriate level to help us

get our product out the door and make the money we need to make, but then no higher. And so just based on that framework, I think that there's probably times when estimation's not worth it, or even to different degrees of certainty are worth it or not worth it right like maybe sometimes an off-the-cuff estimate is the right the right

answer for that situation and it's not really a problem that he says about two weeks maybe it comes down to the business value or what is the value of the thing that you are estimating if it's like look spend a couple weeks like investigating something, like something kind of prototype, something researchy, and the company's not gonna make a ton of money nor lose a ton of money if you do that thing. So spend a couple of weeks, maybe you time box it. You're not saying do X amount of work.

You're saying spend two weeks, come back to me, tell me what you found. Then there's the, if the product does not launch in September, we are in big trouble or, you know, we, we are betting the company on this new product. So we must, must estimate and schedule out its launch date. So we, you know, so we can plan everything around that. And if this launch doesn't go well, we're out of money. So there you want a very accurate and very well-managed schedule. And there's plenty of things in between where, you know, okay, we can have a 75% confidence schedule versus a 50% confidence schedule versus a 25% confidence schedule, depending

on the, you know, the upside and the downside of what if the schedule is right or wrong. Second thing, there aren't really any exciting tools or things that people should be looking for, new methods or processes. They should just sit down with a piece of paper and a pen and think. I use a spreadsheet, but yeah, I was going for Excel. Yeah. Are there new methods and processes that are good? Or am I right in thinking that most of the time planning is just thinking? I personally don't think there are new processes. But, you know, I mean, there are plenty that you could try. But what's worked for me is just doing the thinking and making the guesses

and actually writing down my assumptions and then comparing reality in the future to what happened in the past. And I think, you know, you could probably put a method around that, but those are the fundamental pieces. Yeah. The hard part is making time to think about it and then writing it down and publishing it. Like if you're working for yourself, piece of paper is great. Working with others, you know, whatever wiki word doc google doc whatever it is that shares that you can get it out there but making time to do it and then to communicate it that's it i'm not aware of any microsoft project is perfectly fine silly text file is

perfectly fine excel is great whatever i sometimes uh also, if I'm handwriting it, with Post-it notes. If it's a big interdisciplinary team and you really can move around, like if there are three projects going on and you have mechanical over here and mechanical over there and you need them all to come out on this date, Post-it notes are helpful for moving resources around. Not that people like to be called resources or cogs or minions. There's so many things people don't want to be called. Assets.

Overhead. People love being called overhead. Head count. I think head count. Alicia, when there are bigger projects, but the bigger the head count, at least when there are bigger projects, but the bigger the project gets and you're going to have more concurrency is going to matter and this has to be done before this and this group has to do this, but they can only do one thing at a time because there's only one RF lab

and we can't run the 3D printers in parallel, whatever. Then the tools, yeah, sticky notes or Microsoft Project or some sort of gantt chart but yeah there's i don't i don't think it's a secret sauce or whatever there's smart sheet there's all these online tools but they're essentially the same thing they just let you visualize stuff in time with durations and hopefully stack them up so you can see it all in parallel so there's nothing magic there the hard part is doing the work and then pick a tool and stick with it but both of your answers feed into my feelings about software processes, but I'm not going to go there right now.

You've got to go there now, man. Yeah, you can't dangle that carrot in front of us. No, because we're at the length of Real Genius where the popcorn's starting to come out of the building. We should have estimated the length of this podcast before we started. I could have estimated this was going to be a long one. Yeah, I would have estimated much longer than 50 minutes. Svek, do you have any thoughts you'd like to leave us with?

I feel like people need to understand that I do think estimates are good. I think that people can get better at estimating. I think that people should do estimates and people should understand in their company or their companies why estimates are needed. And you need to have a healthy relationship with all of the users and producers of the estimates in order to make them worthwhile. And you've got an estimate needs to be a living document and you need to have frequent conversations with it or about it. I feel like this whole, if you have trust and empathy for your,

for everyone around you is a lot like the articles. If you have perfect code, it's a big ask. I was. So when, when you said that earlier, I thought of asking all of us, when have we ever encountered that?

And it's like, you're allowed to eliminate iRobot from consideration, but I didn't ask it. But I have had that happen not. There's always management who wants more and doesn't trust engineering. I just haven't been in a company where that's... As a full-time employee.

As a contractor, I've had lots of good experiences, but that's because I'm kind of off to the side. I've had better experiences and I've had worse experiences. And at every company I've worked at four or five companies and, you know, different, different groups, different human beings. I'll say I've had better and worse experiences with them all. But if you are starting from a place of trust and a place of mutual respect, you can, you can go far, right? I'm not trying to make that sound trite, but it's very true with, you know, with less trust and with less mutual respect and more adversarial, then no techniques are really going to be able to help you overcome that very much, which is not a reason to not do estimates.

It's not a reason to not be informing your peers and your colleagues what's going on. But anything you can do to build a better relationship will absolutely pay dividends in all of this stuff going forward. And if you're in a place that has a toxic relationship and you're, you know, you know that you're going to get beaten over the head with the schedule and it's a weapon, it's not a tool, then I don't know what else you can do other than quit. You can still make the estimates because they will still make you better at architecture. They will still make you better at identifying dependencies. And even if nobody listens to them, learning how to do the estimates is a good skill for when you get into someplace that they will listen and you'll be good at it. That is a great, much more positive career focus,

like career development focused piece of advice. That's much better. What she said. Philip, do you have any thoughts you'd like to leave us with? Well, Alicia, that was very well said, which makes it a tough act to follow. For anyone in the audience who's interested in becoming a better estimator, we have a number of articles on our website on the topic of planning and estimation, including a 2021 series we wrote called Improving Our Estimation Abilities, and we'll get links to those articles at it in the show notes. While you're there, if you appreciate that content or any of the other content we

produce, please take a look at our course library and consider becoming a member. Direct support from our readers is what allows us to set consulting aside and focus our time on producing educational content for the community. Our guests have been Chris Speck, Embedded Software Engineering Manager at iRobot. At iRobot. At iRobot. I believe that they prefer iRobot. And Philip Johnston of Embedded Artistry. If you'd like to see discussions like this in real time,

join the Embedded Patreon and get an invitation to the Slack group. Thanks, gentlemen. Thank you very much. This was a good time. Great time. Thank you. Thank you to Christopher for producing and co-hosting. Thank you.

That's Christopher White, by the way. Right just in case there's anybody confused out there. And also, Christopher White is my usual co-host and the man I'm married to. Chris Speck is a good friend, but he lives on a different coast entirely. Okay, thank you to everyone who participates in the Patreon listener Slack group. And thank you to everyone who participates in the Patreon listener Slack group. And thank you for listening. You can always contact us at show at embedded.fm or at the contact link on Embedded FM. If you like the show, please share it or consider writing a review. And now a quote to leave you with.

From Annie Dillard. A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time.