402: We Are a Lazy Species

Transcript from 402: We Are a Lazy Species with Chris Svec, Phillip Johnston, Elecia White, and Christopher White.

EW (00:00:07):

Welcome to Embedded. I'm Elecia 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 Svec and Phillip Johnston to join us again to give us their opinions on the subject.

CW (00:00:27):

I thought we were talking about genres in music and best decades for music. You swindled me.

EW (00:00:32):

Yeah. There are different show notes for you these days.

CW (00:00:34):

Alright, well, I'll see you later.

EW (00:00:37):

Hello, and thank you to the show.

CW (00:00:39):

Thank you to the show?

EW (00:00:41):

Thank you for -

CS (00:00:43):

It's time to play the music. It's time to light the lights.

EW (00:00:48):

Hello, and thank you both for being on the show.

CS (00:00:52):

Hello, thank you for having us.

CW (00:00:54):

Hi, Chris Svec, who I will refer to henceforth as Svec, and hello, Phillip, how are you?

PJ (00:01:00):

Hello. I'm doing good. And thanks for having me back on the show.

EW (00:01:03):

Svec, could you tell us about yourself?

CS (00:01:06):

Sure. I'm Chris Svec. I am a longtime embedded software engineer, and currently I manage the embedded software engineering team at iRobot.

EW (00:01:16):

And Phillip, what about you?

PJ (00:01:18):

I'm Phillip Johnston. I run Embedded Artistry with my wife, Rozi. 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.

CS (00:01:35):

What is an unofficial project manager? Is that like you sneak in in the evenings and do project management when no one's around? What is that?

PJ (00:01:42):

It's kind of like that. If you're on a small startup team and nobody is trying to reign in the chaos, that's usually when I would just step in and try to put some order in place.

CS (00:01:53):

Got it.

EW (00:01:54):

And you said teaching embedded. What's that about?

PJ (00:01:58):

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.

PJ (00:02:09):

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. We're always reinventing the wheel.

PJ (00:02:22):

So I've just been trying to share what I've learned in hopes that it helps other people take that and do something even better with it.

EW (00:02:31):

Embedded Artistry, which is Phillip's company, has a great newsletter and a great blog. So just don't want him to take this part out.

PJ (00:02:40):

Well, thank you.

EW (00:02:42):

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.

CW (00:02:51):

I don't have the document open, so you're going to have to give me 30 seconds here.

CS (00:02:55):

It's time to play the music. It's time to light the lights.

CW (00:02:59):

Yeah. I'm the editor. I can remove all this stuff.

CS (00:03:01):

...I've been on your show enough to know that you can cut a lot of stuff out, man.

CW (00:03:05):

I can cut it all out.

CS (00:03:09):

It can be like the what is it? 432 or whatever.

CW (00:03:13):

Okay. I'm ready. You want me to go first?

EW (00:03:15):

Are you ready, Svec and Phillip?

CS (00:03:18):

Yes.

PJ (00:03:19):

Yes.

CW (00:03:21):

You need to diffuse a bomb. Do you cut red, black, green, or blue?

CS (00:03:24):

Green.

PJ (00:03:25):

Blue.

CW (00:03:26):

You're both dead.

PJ (00:03:28):

That was going to happen anyway.

EW (00:03:30):

Vi or Emacs?

CS (00:03:31):

Vi.

PJ (00:03:32):

Vi. I don't really like either.

CW (00:03:36):

Spaces or tabs?

CS (00:03:38):

Spaces.

PJ (00:03:39):

Tabs. Hardcore.

CS (00:03:40):

Oh, wow.

EW (00:03:41):

C or C++?

CS (00:03:43):

C++.

PJ (00:03:44):

C++.

CW (00:03:45):

Star Wars or Star Trek?

PJ (00:03:47):

I'm pretty heavily in the Star Trek camp.

CS (00:03:50):

Ooh. I'm going to have to go Star Trek. I'm sorry.

CW (00:03:52):

Okay. Well, that's it. I've had it.

EW (00:03:55):

How do you pronounce gee eye eff?

CS (00:04:00):

GIF.

PJ (00:04:01):

JIF.

CW (00:04:01):

God, this is great.

CS (00:04:02):

This is great. We are opposites.

CW (00:04:05):

JPEG or PNG?

CS (00:04:07):

JPEG.

PJ (00:04:09):

I'm a PNG all the way.

EW (00:04:12):

Mac or PC?

CS (00:04:14):

Mac.

PJ (00:04:15):

Mac.

CW (00:04:16):

Oh, well see, there we go. Everybody's happy now.

PJ (00:04:18):

Peace in the land.

EW (00:04:20):

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.

CW (00:04:36):

Are you sure?

EW (00:04:37):

Anyway, can you fight for our amusement now?

CS (00:04:41):

I'd love to. It'd be a great pleasure. I should say that what happened is that Phillip posted 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, this, it bothered me," and I stopped it right there.

CS (00:05:00):

And I made some comment about it. And Phillip said, "No, no, no. 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, well, I at least ended up arguing both sides of estimates, good idea, bad idea, when you need them, and a few other things.

CS (00:05:17):

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.

EW (00:05:27):

I believe, Phillip, you didn't like the idea that software is unable to be estimated?

PJ (00:05:38):

That is true. It's usually, I guess, positioned as, estimating software development tasks, 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.

PJ (00:05:54):

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.

EW (00:06:11):

And so Svec, do you think it's a waste of time to try to estimate software schedules?

CS (00:06:17):

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,...both for yourself and for your team.

CS (00:06:33):

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 -

CW (00:06:46):

Can we - ?

CS (00:06:46):

- which I, yeah, yeah.

CW (00:06:47):

We probably should mention the article and link to it. I don't remember what it was, so maybe make a note to -

EW (00:06:55):

I have it here.

CS (00:06:55):

Okay.

EW (00:06:56):

It's -

PJ (00:06:56):

Platitudes of Doom or something.

EW (00:06:59):

Yes. Platitudes of Doom from Agile Otter, Tim Ottinger's thoughts on Software Development.

CS (00:07:08):

Yeah. Well, and 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...estimatable."

CW (00:07:24):

That's a big if.

EW (00:07:26):

That's a big if.

CS (00:07:27):

The premise of that is if code is bug-free, then we can estimate it. And that's where I stopped. And that's not fair to Phillip's intent for the article, but that is absolutely where I stopped, saying like, "Look, we're not good at estimates."

CS (00:07:39):

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 ridiculous. That is just ridiculous."

CW (00:07:50):

So I did read this, but it was a while ago. And as I am wont to do, I did not prepare for today's podcast. So Phillip, that paragraph reads to me as very weird, not just for the reason that Chris, and I know you're not arguing necessarily for the article or anything, I'm just trying to understand.

CW (00:08:07):

But what about software that hasn't been written yet? That by definition has very clean inputs, because there isn't any.

EW (00:08:16):

No bugs. No bugs at all.

CW (00:08:18):

So when I'm estimating software, I don't usually have a preexisting body of work that I'm building upon all the time.

EW (00:08:27):

Well, how long is it going to take you to do that driver you're supposed to do?

CW (00:08:30):

I don't know how long it's going to take, because I've just started reading the datasheet. But I will have an estimate at some point. But it's a bit ineffable.

CS (00:08:40):

So for the sake of this, would you like me to just say, "Estimates are stupid. There's no point in doing them?"

CW (00:08:46):

No, no.

CS (00:08:46):

...No, I'm just saying...for the sake of our argument here, should I just take that to start with and then have Phillip say, "Well, I don't think that's true." And then we can just go back and forth and see where it goes?

CS (00:08:57):

But I think in reality, there's a middle ground. But I think I'd like us to find that middle ground somehow.

EW (00:09:03):

And yes, Svec, 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.

CW (00:09:28):

Okay. So what does the rest of the article say before we get into this?

EW (00:09:30):

Wait, I had terms I needed to identify.

CW (00:09:32):

Oh, go for it.

EW (00:09:33):

What does ineffable mean?

CW (00:09:35):

Cannot be effed.

EW (00:09:39):

Cannot be understood. And Svec, this one's for you. What is estima, estima -

CS (00:09:50):

Yeah, the word in the article is estimable. Is that a word? I call it estimatable.

CW (00:09:53):

No, it is a word, but it doesn't mean what he thinks it means.

CS (00:09:55):

Oh, it doesn't mean "is capable of being estimated?"

EW (00:09:59):

No, you pointed out that it actually means capable of being liked.

CS (00:10:06):

Oh.

EW (00:10:07):

Esteem-able.

CW (00:10:07):

Which, I will take the position, the radical position, that no software is capable of being liked.

CS (00:10:14):

I think that's just the truth. Computers were a bad idea to begin with.

EW (00:10:20):

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.

CW (00:10:37):

So the rest of the article went on to say that things were estimatable?

PJ (00:10:43):

The article I don't think was about estimations at all.

CW (00:10:45):

Okay. Alright. Alright. My bad.

PJ (00:10:47):

...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've been nothing lost to the article. In fact, I could argue based on what happened as a result of that, the article would've been better, but that one paragraph struck.

PJ (00:11:07):

The article's purpose was, if you think that you are not getting what you want from your software development team, because they're not working hard enough, then that's a problem.

PJ (00:11:21):

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 pushing them to do more and more work just to meet some deadline for whatever dysfunctional reasons we come up with inside of our organizations, that doesn't work.

PJ (00:11:40):

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.

CW (00:11:56):

Okay. And then that just led to the side discussion that we're having now.

PJ (00:11:59):

Right.

CW (00:12:00):

So, Svec, why is estimating difficult?

CS (00:12:06):

Estimating is difficult because by definition, you're doing something you haven't done before. And so there's the famous, "You know what you know, and then you know some of what you don't know. And then there's plenty of unknown unknowns. You don't know what you don't know."

CS (00:12:25):

One of the reasons why estimating is difficult is because you are predicting the future. And we all know we're not terribly good 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.

CS (00:12:49):

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.

EW (00:13:08):

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...it's not defined. We can't estimate something that isn't well-defined.

CS (00:13:24):

Right. And, I mean, a very poor behavior 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."

CS (00:13:36):

"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, go away." Just, "You'll get it when you'll get it. Leave me alone." And so that is -

EW (00:13:47):

It does take a long time to put together an estimate, especially if you're trying to do a good one.

CS (00:13:52):

Exactly. Exactly. And again, I'm playing devil's advocate here, but yeah, 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.

CW (00:14:04):

Time spent learning to code is time I could have been spending coding.

EW (00:14:09):

Well, no, I mean -

CW (00:14:09):

Sorry.

EW (00:14:10):

Haven't you ever been in a meeting where it's a schedule update, and it's just totally useless?

CW (00:14:16):

I worked at a place that had...a room that was just the schedule. Every wall was covered in Microsoft Project.

PJ (00:14:22):

Well, I think that's where a lot of the dislikes of estimates come from.

PJ (00:14:28):

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.

PJ (00:14:42):

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.

PJ (00:14:56):

And we just keep doing this in circles around the room until we have a plan for the next two weeks, or 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.

PJ (00:15:10):

So of course, if that's your experience,...that's absolutely horrible. And I hate it just as much as everyone else,

EW (00:15:16):

But there's another experience where I actually put in a lot of time for my estimates. I thought about it. I thought about what 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.

EW (00:15:32):

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.

EW (00:15:47):

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.

PJ (00:16:00):

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.

PJ (00:16:10):

So Rozi and I had joined in this company together, and we came up with a schedule that we thought was an aggressive schedule that, there's a lot of risk involved, but we think we could hit the schedule. They just didn't want to accept it, because it was two months after their target ship date.

PJ (00:16:28):

So I quit, because I just wasn't going to do that again. And looking for the news updates, they shipped two weeks after the schedule that we created. And...that totally happens.

PJ (00:16:41):

And I think part of the dysfunction, too, maybe that's another symptom, is going from, "We have a schedule, and we need to craft estimates that show that we can meet our schedule," rather than the other way around of trying to think of how long the work's actually going to take.

PJ (00:16:55):

And if you have a target date that you want to get, and if you have an estimate, and you don't 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 showing you that you probably have too much work for whatever timeframe that you have.

PJ (00:17:15):

And there's always valid reasons for why we have to ship in September instead of November.

PJ (00:17:21):

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?

PJ (00:17:43):

What features were we just really aiming for to try to differentiate ourselves, but they're not really core to the experience? There's a lot of different ways you can manage the estimate is too long versus the time we have available problem.

CW (00:17:59):

But...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 locked down scheduled date," which I bristle at every time it happens. But it happens just about every time.

CW (00:18:18):

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 who 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.

CW (00:18:35):

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.

EW (00:18:44):

A shortcut.

CW (00:18:44):

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 or to be accepted. And 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.

CS (00:19:05):

...I want to go back -

CW (00:19:07):

Yeah.

CS (00:19:07):

- and make sure I understood what Phillip just said real quick, Chris. So Phillip, what I'm hearing is that, what I think you said is that, some group comes up with a schedule, and sometimes for a very good reason, valid business reasons, "We must launch in September."

CS (00:19:25):

And a skilled estimator then comes up with, "Okay, we can launch everything you want in November." And there's some valid reason that everyone agrees to this, says, "Look, September is it."

CS (00:19:35):

So it sounds like what you're saying, Phillip is, at that point, that even if the schedule's 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?"

CS (00:19:46):

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."

PJ (00:19:55):

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...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.

PJ (00:20:16):

We have other scarce resources for doing what we need to do. 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...We're not working alone to try to solve problems.

PJ (00:20:33):

And if we are then who cares about your estimate, really?...You don't have anybody to answer to or to coordinate with. Don't worry about estimation, probably doesn't matter.

PJ (00:20:42):

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 constrained resources we have, and to come together to deliver a product, you need some way to determine what work gets done.

PJ (00:21:07):

And...we can estimate in different ways, whether the estimated cost, the estimated time, is worth the estimated value that is going to be delivered to our business or to our customers from doing that particular thing.

PJ (00:21:24):

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 ten teams that we need to coordinate 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.

PJ (00:21:41):

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. There's just all these different concerns that have to line up.

PJ (00:21:52):

And to do that 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.

CS (00:22:12):

Alright. 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.

PJ (00:22:20):

Right. Fair enough. Yeah. Right now you have infinite time to work on your software, because you can't ship your hardware.

CS (00:22:28):

Backing up, I mean, I think we started this thinking, "Oh, maybe we could do kind of a debate." But it seems like we're kind of stating some different things about why estimates are good, and they're valuable. And I think two thoughts come to mind.

CS (00:22:43):

One,...the people who are involved here, the quote unquote business people, and the quote unquote engineers, there needs to be a level of trust and respect if a deadline and a schedule are going to be a useful task as opposed to kind of an offensive task, or a weaponized task, or something like that.

CS (00:23:04):

If the business has a schedule and they don't care what you say, and they're not willing to not willing to negotiate what scope might go into it, and if they're just like, "Look, I don't care. Everyone work 400 hours a day, because we have to hit September," it doesn't matter.

CS (00:23:21):

No better schedule or no better estimating techniques is going to help you there.

CS (00:23:26):

But fortunately I've mostly been in places where, whether it's the business, or the marketers, or whoever it is 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 relationship there where.

CS (00:23:46):

"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?"

CS (00:23:57):

But if we go in supposing an adversarial relationship between the CEO, and the business development, and the engineers, you're kind of hosed from the start.

PJ (00:24:07):

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..., I think we're doing it here today, as we talk about our experiences and where we see the value.

PJ (00:24:23):

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.

PJ (00:24:35):

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.

EW (00:24:49):

But, but, but, but -

CW (00:24:51):

Yeah, hang on a second.

PJ (00:24:52):

Okay.

EW (00:24:53):

Software engineers really are bad at estimating things. I mean -

CW (00:24:57):

Some software engineers are bad at estimating things.

EW (00:24:59):

Almost all starting software engineers are bad at estimating.

CW (00:25:02):

Fine.

CS (00:25:03):

Most software engineers are terrible at software engineering as well, when they start. And again, I shouldn't be arguing this, because aren't I supposed to be arguing that 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.

PJ (00:25:21):

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?...

PJ (00:25:27):

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, "Okay. Just maybe I need to increase my fudge factor next time," that often isn't there.

PJ (00:25:52):

So if you don't practice a skill, of course you're not going to be good at it. 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 long it's going to take you to do software work.

CS (00:26:06):

It's interesting, because...the only software estimation tool that I've ever seen that actually gives you that feedback was FogBugz, 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.

CS (00:26:22):

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.

CS (00:26:30):

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."

CS (00:26:43):

So it seems like that kind of feedback is necessary to actually learning how well you do estimate and then hopefully getting better at it going forward. Are there any other tools, or -

EW (00:26:55):

Yes.

CW (00:26:56):

Yes. And I hate myself for saying this,...and I have something else to follow up with this, but anyway -

EW (00:27:05):

We all do.

CW (00:27:06):

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 at what points..., and then for the next sprint, we would only do the number points that we actually made on average.

CW (00:27:25):

I mean,...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?

CS (00:27:47):

I have many complicated feelings about agile. I think....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. Yeah, that right there just shoots any credibility it has in the foot.

CS (00:28:06):

But...the time horizon of agile is one week sprint, two week sprint, three week 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.

CS (00:28:27):

And please edit this out if it doesn't make sense. But when Elecia said in the first place, she said, "Hang on...I spent good, hard time, and I built what ended up being a correct estimate."

CS (00:28:39):

"And I had to think about it. I had to sit down. I had to spend...minutes and hours actually, diving in, breaking up big problems into smaller problems, break those smaller problems into even smaller problems. And then estimating it out." I think fundamentally human beings do not like expending energy period.

CS (00:28:57):

We are a lazy, lazy species, and I am absolutely part of that. And so estimating is a very mentally difficult task, because, "Build me an embedded Bluetooth temperature monitor." "Okay, sure. That'll take a month." Okay. That's all the energy that my brain wants to use on it.

CS (00:29:21):

I forget which books I've read, but our brain actually doesn't like expending energy. Because it wants to be efficient, right? So are you groaning because you disagree with that, Chris?

EW (00:29:31):

I want to go back to the feedback thing.

CW (00:29:31):

Well, I want to respond to what he said first.

EW (00:29:33):

Okay.

CW (00:29:34):

Because I totally disagree...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.

CW (00:29:52):

"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 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.

EW (00:30:12):

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 -

CW (00:30:18):

Okay.

EW (00:30:18):

- about how estimation and design really overlap. And I want to go back to feedback and learning -

CW (00:30:26):

Okay.

EW (00:30:26):

- the skill of estimating.

CW (00:30:28):

Cool.

EW (00:30:28):

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.

EW (00:30:41):

And at the end of the projects, after a couple of years of doing that, I kind of had my own fudge factor figured out. And the person here who is probably the best at estimating is Phillip. And I want to know how he got good at it. How did you get that feedback? He went for a coffee.

CW (00:31:02):

Beyond that. How do you do it? What is your process? Because you do something that in consulting I find terrifying.

EW (00:31:09):

Fixed-bid projects.

CW (00:31:10):

You do fixed-bid projects.

CS (00:31:11):

So what does Phillip do? Because I think...on the call we all know what Phillip does, but maybe Phillip should explain that.

PJ (00:31:17):

Yeah, sure.

PJ (00:31:18):

So something that I practice within my business that is very different from every other software consultancy I've ever known, and people just sling a lot of insults about this, and say it will 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.

PJ (00:31:39):

But when it really makes sense is never risk. It's usually just, "Yeah, you can call me whenever you need to to ask me a question. I'll bill you by the hour."

PJ (00:31:48):

So how we got good at it is just, I've been thinking about it for 12 years and getting this feedback continually, originally with making estimates for how long things would take because I was asked and writing that down in a paper notebook.

PJ (00:32:05):

And 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 I was already kind of in the habit of tracking how long individual tasks took and what project it was allocated to.

PJ (00:32:21):

And so I kind of had that data to compare to, and just 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.

CS (00:32:39):

So this sounds like this sounds like deliberate practice, which seems a little -

PJ (00:32:42):

Deliberate practice it is.

CS (00:32:44):

Yeah. So it's a little, pop culture kind of a thing, Malcolm Gladwell's 10,000 hours that he popularized....I think it's 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.

PJ (00:33:03):

Right. And 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 had a consistent tendency to one, estimate that I would spend eight hours a day working on a given task.

PJ (00:33:24):

And in reality, what I spent on a given task was closer to two hours a day, which...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.

PJ (00:33:38):

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.

PJ (00:33:51):

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 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.

PJ (00:34:07):

It's not the time I spent writing the documentation. It's not the time I spent taking the review feedback, and 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.

PJ (00:34:23):

So I just would habitually miss all of that which,...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..., of course you're going to be wrong.

PJ (00:34:38):

And so...for myself, I noticed that I had this personal tendency to make these assumptions or to ignore these vast areas where...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 get caught now, because I have a partner.

PJ (00:34:56):

So whenever we're making a proposal for a client 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.

PJ (00:35:13):

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...sort of 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?

PJ (00:35:32):

And then I have Rozi, who was a project manager, I think, for 20 years now, give or take a few years, review my work. And she can always find things that I'm still failing to account for.

PJ (00:35:42):

A big one is I'm failing to account for the time that she's going to spend on the project, 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 the necessary time delays I need to account for.

PJ (00:36:02):

Because the client needs time to get me feedback that I can respond to. So I think...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 to a point where I feel confident in my estimates is, I do get that feedback.

PJ (00:36:20):

And I get often get that feedback early enough that I can adjust my estimate before I actually hand it over to someone.

EW (00:36:27):

Does 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?

CS (00:36:38):

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 you are fortunate enough to work for or with Phillip or Rozi there, you're going to see, look, estimates are possible.

CS (00:36:56):

You have to sit down, and to think them through, and think through the decomposition of problems, and estimate it, 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."

CS (00:37:12):

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?

EW (00:37:21):

You're arguing the wrong side, Svec.

CS (00:37:23):

Oh, sorry, sorry. Phillip is wrong. Phillip is wrong. And his business is out of business, and he doesn't realize it.

CW (00:37:29):

Can I ask Phillip 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?

CW (00:37:53):

If I hand you, "Oh, I need an I2C 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 datasheet."

CW (00:38:09):

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?

PJ (00:38:25):

So 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 in very narrow areas.

CW (00:38:40):

Okay.

PJ (00:38:40):

Embedded software development, build systems, there's a couple areas like that that I feel confident in. Now,...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.

PJ (00:38:55):

Because...I do that as a toy project for myself or something internal, but not to a professional degree. So there are things that, because I lack the knowledge, I can't estimate them.

PJ (00:39:11):

But that doesn't mean that somebody on my team can't, or somebody I know can't, or another individual could probably create a perfectly reasonable estimate.

PJ (00:39:20):

Now to answer your actual question, what I usually do, I have a good sense of when I'm trying to decompose the problem...where a given area of development is well-defined or not.

PJ (00:39:41):

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.

PJ (00:39:57):

So for something like there's a brand new chip with an alpha datasheet, 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.

PJ (00:40:09):

So personally for something like that, I do have a good sense of, if it goes well, it's going take me a certain amount of time. If it goes poorly and we have design problems we're working out,...it's an indeterminant amount of time.

CW (00:40:21):

Yeah.

PJ (00:40:23):

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."

PJ (00:40:46):

"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.

CW (00:40:57):

Okay.

PJ (00:40:58):

That's how I would do it...And I'd give that proposal to somebody. They could very well say, "[Nah], we don't like that plan," and go to somebody else.

CW (00:41:07):

Yeah, yeah.

PJ (00:41:07):

And I think, great, that's fine.

EW (00:41:10):

So you can do a fixed bid for a part of the project and then another fixed bid for the next part.

PJ (00:41:20):

Yes.

CW (00:41:20):

Which is just what I do. I do a fixed bid for every hour. It's always the same. Okay. Well, thank you. That makes a lot of sense, actually.

EW (00:41:31):

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?

CS (00:41:58):

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...

CS (00:42:13):

As we discussed already, you need to be able to give some target date for other parts of the business, for somebody else 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.

CS (00:42:32):

And there's a lot of coordination and a lot of dependencies that go into that. So that's one point of it...It's sort of a trite phrase that, "Oh, no one has requirements aren't real. The requirements aren't good enough."

CS (00:42:46):

The act of estimating, and this is what Elecia said earlier with her successful estimating work, the act of estimating forces you to discover more requirements...

CS (00:42:56):

You might be like, "That'll take me about three months or three days," forces you to break it down into 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 weeks."

CS (00:43:12):

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.

CS (00:43:21):

But those are just the couple of reasons why you might bother with an estimate or what an estimate's good for that I can come up with that. Did I miss any big ones?

EW (00:43:29):

Well, since you're arguing the wrong side again, maybe we should go to Phillip.

PJ (00:43:37):

I don't think you missed anything. I think that was a good list. I do think 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.

PJ (00:43:53):

I don't know how to argue the other side, Elecia. I'm sorry for that.

EW (00:43:58):

Well -

PJ (00:43:59):

It's like you just throw your hands up and say, "Oh, it's too hard. We're not going to do it."...Nobody really wants that option either.

CS (00:44:06):

Actually I would argue there.

PJ (00:44:07):

Okay.

CS (00:44:07):

I think a lot of engineers, if they assume, "Estimating's too hard." There's no point to it. "Look, 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?

CS (00:44:21):

Anyway, that's a common attitude is, "Throw up your hands. Forget it. I'm taking my ball, and I'm just going to go and code instead of estimate."

PJ (00:44:28):

I think that would work as an individual.

PJ (00:44:31):

But...once you get up to being a team lead or for me,...I'm in business, I can't go to a prospective client and say, "I don't know. So we're 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."

PJ (00:44:47):

That's never going to work regardless of whether or not you're team lead or in business. So...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.

CS (00:45:04):

There's maybe a career maturity there that, certainly 22-year-old me wanted to throw up my hands in disgust and just walk away. 25-year-old me probably did too.

CS (00:45:15):

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.

CS (00:45:30):

The argument of I'm going to throw up my hands just kind of goes away.

CW (00:45:35):

...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.

CW (00:45:54):

But where I have heard the 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, we should treat those as malleable Jell-O."

CW (00:46:09):

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 also...it's a copout to, "Well, we don't really know what we're building at any given time."

CW (00:46:25):

And that seems like the pernicious core of a lot of this is, "Oh, requirements change. So don't bother."

EW (00:46:35):

It sounds like you don't like agile.

CW (00:46:37):

That's well-known. But how many of us have had t-shirts that they've had to sign committing to a schedule?

PJ (00:46:45):

I have never heard of such a thing.

CS (00:46:47):

Is that a thing?

CW (00:46:47):

Oh, 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.

EW (00:46:59):

...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.

EW (00:47:18):

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.

EW (00:47:36):

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.

EW (00:47:53):

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.

EW (00:48:14):

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.

CS (00:48:26):

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.

CS (00:48:44):

...I at least feel like there is a negative connotation around them. However, Elecia, yes, Gantt charts are the only visualization that I know of that shows exactly what you said.

EW (00:48:54):

There are some bad uses of estimating estimates and that whole process. Svec, since that's what you're arguing for, what are the wrong ways to use estimates? Not to do estimates, but to use them.

CS (00:49:13):

One-time efforts that are punitive or punishment-driven in nature. So...a bad thing you can do is come up with an estimate at the beginning of a project, especially a longer project. And the engineering team spends a reasonable amount time, comes up with a good faith estimate.

CS (00:49:32):

They present it to the stakeholders, whoever's going to kind of 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."

CS (00:49:45):

Then no one talks about the schedule ever again, other than, "Are you done yet? Is it September? Are you done? Are you done? Are you done?" And no one takes any changes into scope, or new discoveries are made. Good things happen. Bad things happen. No one revisits the schedule.

CS (00:50:01):

Instead it's treated like 10 commandments have been chiseled in stone.

CS (00:50:05):

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 we have to wait for another tapeout of another silicon rev to get through."

CS (00:50:20):

"I don't care. You all are in trouble, because you didn't hit your deadline." So those are some terrible uses of estimates.

EW (00:50:27):

Do you have anything to add, Phillip?

PJ (00:50:30):

No. Having lived through it, I'm just kind of shaking here in the corner with a little bit of PTSD.

EW (00:50:35):

There's also the opposite of what Svec said where you don't touch them. There's also the demanding an update to estimates every week or every day -

PJ (00:50:46):

Yep.

EW (00:50:46):

...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.

PJ (00:50:57):

Yeah. I agree that doing estimates too often is problematic. I mean,...having an idea of what you need to use your estimates for, I think is important. And...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."

PJ (00:51:20):

But I do think that both of those kind of hint at something that is important about estimates as 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.

PJ (00:51:36):

And if the estimates are wrong and your schedule is based on estimates, at some point you do need to look and see, "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.

PJ (00:51:52):

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. I've been a part of that kind of thing.

CS (00:52:11):

So Phillip, how do you set expectations with your clients? Obviously...they're coming to you, so 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 end points there..." How do you set expectations with them?

PJ (00:52:27):

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 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.

PJ (00:52:47):

And I do say an estimated schedule. So...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."

PJ (00:52:59):

But I do make it clear that 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 I can't go ask for more money, right?

PJ (00:53:12):

So I have to be reasonably sure about what I'm doing, to some degree, to take the risk that I'm going to run into some unknown bug, and it's going to reduce my profit on a given project, but not bankrupt me, or taking out loans, or taking on other work so I can pay the bills.

PJ (00:53:28):

Because I'm having to do something for a client that I didn't anticipate. But I do think 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.

PJ (00:53:42):

I try to at least once a week, give a picture of where I'm at, the work I've done, whether or not we think things are going to take longer, or 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.

EW (00:54:00):

Do people get angry when you come in ahead of schedule, and they feel like they've overpaid?

PJ (00:54:05):

No, never.

EW (00:54:06):

Good.

PJ (00:54:08):

...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, whenever I did some work and whenever they had time to review what I had done.

PJ (00:54:23):

And then one, I get this email. And they're asking when it's going to be wrapped up, because the project's dragging on too long, which is funny, because it was an exploratory project from their side.

PJ (00:54:38):

So I have a call with the CEO, and he tells me that he would've rather have had all the work I did done in a week for 10x the money just to have it done in a week.

PJ (00:54:50):

And I was like, "Oh, okay. Well, if that's how you're looking at it from the CEO's perspective," that the shorter time to get the feedback is worth the higher cost, that sort of motivated me to start exploring this.

PJ (00:55:02):

"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 maybe there's some upside there for me, if I can pull that off."

PJ (00:55:17):

And since I've taken that model nobody's complained if I get done sooner and they paid a certain amount of money.

PJ (00:55:23):

People have complained on the hourly end where...we told them that we had an estimate of whatever, but...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.

PJ (00:55:40):

None of that's happened since we had fixed price work, which I'm very surprised by and grateful for.

EW (00:55:47):

Do you have to deal with codebases that you didn't make?

PJ (00:55:54):

Yeah, I think most of them. Yeah.

EW (00:55:56):

I mean I find myself helping clients solve other bugs. And so I can't imagine doing fixed bid, 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.

CW (00:56:17):

Sounds like you just don't take those kinds of things, Phillip. You focus on one area and that's what it is.

PJ (00:56:24):

I do take those kinds of things, but I don't necessarily structure it maybe in the way that's like, "We're going to fix this bug. And this is the cost for fixing that bug." If I'm helping somebody's team do it, it might be like, "Well, I'm going to give you two weeks of my time. And here's what that looks like. And here's the price for that."

PJ (00:56:45):

And 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 10 joint debugging sessions of four hours in length for a certain price.

PJ (00:57:00):

So there might be times that I do something like that, where it is a little more nebulous in terms of solving a problem, or coaching a person, or even just refactoring something to make it a little easier to work with.

PJ (00:57:11):

But you're right that it's hard...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.

PJ (00:57:31):

Because...once you 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.

EW (00:57:40):

Well, half the time of fix is a one-line thing.

PJ (00:57:43):

Totally.

EW (00:57:44):

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 -

CW (00:58:11):

He's explained it already.

EW (00:58:12):

I know. I know, but it's just so mind-boggling. Okay. How about this.

CW (00:58:16):

And sometimes he's wrong. I don't think he'd say that he's -

PJ (00:58:18):

Sometimes I'm wrong.

CW (00:58:18):

- right every time.

PJ (00:58:20):

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."

CW (00:58:32):

And I didn't help at all.

CS (00:58:33):

Are you saying that's how bad off you were? You had to call Chris?

CW (00:58:37):

Yeah. That's exactly what he was saying.

PJ (00:58:38):

He wasn't involved at all.

CW (00:58:40):

I offered him zero actual help if I recall correctly.

PJ (00:58:44):

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.

PJ (00:59:03):

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 it worked on other projects in the intervening years. And so didn't really have a good memory.

PJ (00:59:17):

And that,...it was unknown if there was ever even going to be a solution, and it was just luck. It was truly luck that one day I decided to flip one bit and we noticed that...we're suddenly receiving radio traffic when we weren't able to before.

PJ (00:59:34):

But...yeah, I don't have a good answer. Sometimes you just suffer, I think...And I think this is true of most projects when they get derailed, they're derailed from one major issue that takes an indeterminate amount of time to solve.

PJ (00:59:50):

And nobody has any line of sight for how it will be solved, but solving it is key to the actual project being completed. And I guess the goal is, as much as possible, to avoid those.

PJ (01:00:03):

But sometimes they do happen, and for a fixed price bid, then yeah, you take your loss. You lose your profit. And hopefully...you're not working for free and getting behind on your bills because you're going that hard on it. And maybe if you get into that situation, here's the truth. I went to the client in that situation.

PJ (01:00:26):

I was like, "Look, we need to figure something out, because...this could go on for months." And we estimated this project on a, I forget, but maybe a four-week time frame. And...here we are on month four...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.

PJ (01:00:46):

So that happens. And I think, again,....you have to have the hard conversations. And sometimes they don't go the way you want, and they're very uncomfortable. 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 show for it?"

PJ (01:01:03):

And they're going be just as happy as me coming to them and saying, "I need more money?"...I don't see that either playing out very nicely.

EW (01:01:13):

It's funny, I've done a couple of the impossible bugs lately. And...I can't say this out loud. I don't usually end up charging for them.

PJ (01:01:24):

Right.

EW (01:01:25):

Because it -

CW (01:01:25):

Excuse me. What?

EW (01:01:26):

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.

CW (01:01:34):

And yet I can't have my coffee maker.

EW (01:01:38):

That's a marital thing.

CW (01:01:41):

Fixing one impossible bug would've paid for it.

EW (01:01:44):

It's true. And so I have thought, "Well, maybe I should be 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've offered a decent amount of money,...that's charging for experience instead of time.

CW (01:02:11):

I want to flip this around a little bit.

EW (01:02:13):

Because I've gotten totally off.

CW (01:02:14):

Svec, you work with contract people. What is it like from the other end? What are your expectations?

CS (01:02:22):

...First of 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 so -

CW (01:02:35):

You can't flip. We've already flipped. Now if you flip it around we're back where we were.

CS (01:02:39):

It's a three-sided point.

CW (01:02:41):

Okay.

CS (01:02:41):

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.

CW (01:03:00):

Yeah.

CS (01:03:00):

I work with a bunch of people. But then we keep working together over and over for eight, eight plus years, right? So there's a different type of relationship. There's a long-term relationship that can be built up there. And so I've probably worked on 20 different projects over the last couple years with a bunch of different people.

CS (01:03:19):

And the good thing is that some of these projects are short little things, and some of them are six months or even a year or a year-and-a-half-long projects. And the good thing is that...everyone has kind of the same idea of what a schedule is, of what an estimate is.

CS (01:03:33):

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 weeks. We'll come up with a schedule."

CS (01:03:43):

We say, "Okay...We are 75% certain that we will be able to get done by September. And we think we have a milestone one in April, and we have milestone two in July.

CS (01:03:55):

"And then we think we'll be done in September. And 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 processor," whatever it is. And then we have this conversation with the business, with the product person. And...there's a lot of empathy going on here.

CS (01:04:16):

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...I say, "You know what? If I can get a third person working on this, then I can burn down that risk sooner."

CS (01:04:31):

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 we have that conversation.

CS (01:04:37):

Then a month or two in, because there is a long-term relationship here, it's very easy to be like, "Alright, we do our monthly project review," and "Okay, these two things went sideways, and so unexpected things came up. So September is not doable unless we cut X, Y, Z. Otherwise it's November."

CS (01:04:54):

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 on 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.

CW (01:05:09):

I've never been in a company long enough for that to develop.

EW (01:05:15):

I've had some good teams that worked with -

CW (01:05:18):

I've had good teams. I've had good teams, but...they were serendipitous. It wasn't due to long-term -

EW (01:05:25):

Empathy?

CW (01:05:26):

Sure.

CS (01:05:27):

I had to bring that word out. I'm contractually required to use that word on this podcast.

EW (01:05:32):

I think cows has to be said by you as well.

CW (01:05:35):

Cows?

CS (01:05:36):

Excellent.

EW (01:05:38):

Phillip, 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?

PJ (01:05:56):

Are we talking personally or for consulting clients? Because...I handle those differently.

EW (01:06:05):

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, HAL hookup into multiple smaller day-long projects?

PJ (01:06:24):

I think it depends on my comfort with the project. I would say for things like I2C driver, I would probably make that 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 that just is the currency of the business to some degree.

PJ (01:06:47):

But...for things that I'm not as confident in or just I haven't done them as many times, I will break them down into the finer grain steps of whatever I see it as...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."

PJ (01:07:11):

"And then I'm going to get that imported into the system." 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 I guess as a checklist in some sense, and just to make sure that I really understand what I'm going to be doing.

PJ (01:07:33):

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 at a very high level.

PJ (01:07:52):

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...I'm pretty sure I keep everything in hours that I write down.

EW (01:08:08):

I've been told that 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.

PJ (01:08:22):

I don't think, 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. If you think it's going to take two days, it's probably going to take four.

PJ (01:08:33):

But I don't think on the breaking it down. For me, it's all about what I see as the risk...I'm making estimates for myself and for my clients so I'm not trying to make up a number to get out of something...If you're rating something and you pick a seven, it's like, "Nope, seven's not allowed." For my own estimates I don't have that rule.

CS (01:08:58):

Yeah...Having projects where we have five, six software engineers, a couple electrical engineers and a bigger team working on it, if only one person understands a particular area, and they come back, and they say, "It'll take about two weeks," I sometimes might kind of dig in.

CS (01:09:18):

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, "Alright,...let's break it down some," not because it's like, "Oh, I don't trust your estimate."

CS (01:09:38):

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...I think it's kind of like what you said. It's the risk element.

CS (01:09:54):

But when you start dealing with other people, then suddenly you have to remember, if someone's done motor drivers since they were seven years old, and they can write them in their sleep then, yeah. Yeah.

CS (01:10:03):

When someone tells me two weeks, she'll nail it, because she's done this a million times. But if it's newer, then there's more risk involved.

PJ (01:10:11):

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."

PJ (01:10:23):

"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." ...If an estimate is too off-the-cuff, it's suspect. And maybe two weeks is something that some people will say.

PJ (01:10:42):

But I just think that there's, 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.

CS (01:10:51):

Yeah. I mean, I've definitely been in the situation when our executive VP of engineering, some topic comes up and I'm in the executive team meeting, and they're like, "Alright. Oh my goodness. We have to fix something or we have to do something. How long is that going take?"

CS (01:11:03):

And the first thing I say is, "I don't know. And the team will go back, and in a week we will have a more intelligent schedule for you." And then if pressed, then you can start saying, "Look, order of magnitude, this is a six-month project," or, "This is a three-month project." That could mean two months. That could mean six months.

CS (01:11:26):

And 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. And I'm not going to tell you it's going to be 10 years for something that I actually think will cost will take six months."

CS (01:11:42):

"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 hard time thinking about it and getting whatever details you want.

EW (01:11:57):

Phillip, when you and Svec 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?

PJ (01:12:19):

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...You're going to meet up with a friend somewhere, and you're leaving, "I'll be there in 20 minutes."

PJ (01:12:36):

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.

PJ (01:12:55):

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." ...Yes, sometimes we're right.

PJ (01:13:07):

We even tend to have the same kind of biases where 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.

PJ (01:13:20):

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, "[Ah], I have no idea 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.

PJ (01:13:34):

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 the conditions are if you leave at different times.

PJ (01:13:47):

And so we have all these ways when we travel that 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 willingness to make them, and to use those to plan our days, and figure out when we need to leave.

PJ (01:14:06):

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.

PJ (01:14:23):

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...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.

PJ (01:14:37):

There are other people who have done it, who have a lot of experience with it, that can be consulted. Within a company...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 -

EW (01:14:53):

Distributed unevenly?

PJ (01:14:56):

Fair enough. Distributed unevenly. We're all good at different things. And we have different experiences. And 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.

PJ (01:15:13):

And so I think, for that reason, I really like to think about travel and software estimation as being quite similar to each other.

EW (01:15:22):

I'm glad you brought up the people who habitually get it wrong and how other people make allowances for them. And there are people who, if you're not five minutes earlier, 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.

PJ (01:15:42):

Hitting all the red lights.

EW (01:15:42):

Which only makes you a little bit late. But if you are going for a job offer or job interview, that's important.

CS (01:15:51):

I love that analogy, because I think you take it one step further. And....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.

CS (01:16:03):

But if it's, "Hey, Phillip, let's meet at the restaurant. Phillip, I'll meet you at two o'clock," you are the product, the product owner, or the business. You are the other part of the estimate there.

CS (01:16:17):

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.

CW (01:16:29):

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."

CW (01:16:38):

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 Svec.

CS (01:16:54):

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.

PJ (01:17:06):

Now I'm going to push back on this a little...Should we estimate everything? Are there tasks or sets of work that we think shouldn't be estimated or - ?

EW (01:17:18):

Bathroom breaks?

CW (01:17:22):

Yeah. I think where you're headed was, is this a research project with no visibility? Is that worth estimating?

PJ (01:17:32):

Or even from a sprint planning perspective, I'm not clear that I think that estimating the amount of work that you can get done in a sprint is -

CW (01:17:40):

Oh, I see. Yeah. Yeah.

PJ (01:17:41):

- is even worth that amount of effort. So I have a hard time, because I am very pro-estimates. But I'm also very anti-estimates in some ways where I do think that it's an expense to make an estimate, and good business is not just increasing expenses blindly.

PJ (01:18:03):

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, -

CW (01:18:27):

Right, right. Yeah.

PJ (01:18:27):

- worth it or not worth it, right? Maybe sometimes an off-the-cuff estimate is the right answer for that situation. And it's not really a problem that he says, "About two weeks."

CS (01:18:37):

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 investigating something. Something kind of prototype, something researchy," and the company's not going to make a ton of money nor lose a ton of money if you do that thing.

CS (01:18:54):

So spend a couple weeks, maybe you timebox it. You're not saying, "Do X amount of work." You're saying, "Spend two weeks. Come back to me. Tell me about what you found."

CS (01:19:03):

Then there's the, "If the product does not launch in September, we are in big trouble," or, "We are betting the company on this new product so we must estimate and schedule out its launch date so we can plan everything around then. And if this launch doesn't go well, we're out of money."

CS (01:19:21):

So there you want a very accurate and very well-managed schedule. And there's plenty of things in between where, "Okay, we can have a 75% confidence schedule, versus a 50% confidence schedule, versus a 25% confidence schedule," depending on the upside and the downside of, "What if the schedule's right or wrong?"

CW (01:19:42):

Second thing, there aren't really any exciting tools or things that people should be looking for, or new methods, or processes. They should just sit down with a piece of paper and a pen and think.

PJ (01:19:55):

I use a spreadsheet, but yeah, I think that's pretty good.

EW (01:19:57):

I was going for Excel, yeah.

CW (01:20:00):

Are there new methods and processes that are good? Or am I right in thinking that most of the time planning is just thinking?

PJ (01:20:09):

I personally don't think there are new processes. But I mean, there are plenty that you could try.

PJ (01:20:15):

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 could probably put a method around that, but those are the fundamental pieces.

CS (01:20:33):

Yeah. The hard part is making time to think about it, and then writing it down, and publishing it. If you're working for yourself, a piece of paper is great. Working with others, whatever Wiki, Word doc, Google doc, whatever it is that shares that you can get it out there.

CS (01:20:49):

But making time to do it and then to communicate it, that's it...Microsoft Project is perfectly fine. A silly text file is perfectly fine. Excel is great. Whatever.

EW (01:21:02):

I sometimes also go, if I'm handwriting it, with post-it notes. If it's a big interdisciplinary team, and you really can move around, 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.

EW (01:21:24):

Not that people like to be called resources, or cogs, or minions. There's so many things people don't want to be called.

CW (01:21:31):

Assets.

CS (01:21:36):

Overhead. People love being called overhead.

CW (01:21:39):

Headcount.

CS (01:21:39):

No, I think, the headcount [laughter]. Elecia, when they are bigger projects, but the bigger the project gets..., more concurreny's going to matter.

EW (01:21:50):

Yeah.

CS (01:21:50):

"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...," whatever. Then the tools. Yeah. Sticky notes, or Microsoft Project, or some sort of Gantt chart.

CS (01:22:06):

But yeah, I don't think there's a secret sauce or mode. There's Smartsheet. 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.

CS (01:22:18):

So there's nothing magic there. The hard part is doing the work and then pick a tool and stick with it.

CW (01:22:23):

Both of your answers feed into my feelings about software processes, but I'm not going to go there right now.

CS (01:22:28):

You've got to go there now, man.

PJ (01:22:30):

Yeah. You can't dangle that carrot in front of us.

CW (01:22:33):

No, because we're at the length of Real Genius where the popcorn's starting to come out of the building.

CS (01:22:39):

We should have estimated the length of this podcast before we started.

EW (01:22:43):

I could have estimated this was going to be a long one.

PJ (01:22:46):

Yeah. I would've estimated much longer than 50 minutes.

EW (01:22:52):

Svec, do you have any thoughts you'd like to leave us with?

CS (01:22:56):

Yeah, 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.

CS (01:23:08):

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...estimate needs to be a living document. And you need to have freaking conversations with it or about it.

EW (01:23:21):

I feel like this whole, if you have trust and empathy for everyone around you is a lot like the article's "if you have perfect code." It's a big ask.

CW (01:23:34):

...So when you said that earlier, I thought of asking all of us, "When have we ever encountered that?"And Svec, 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.

CW (01:23:53):

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.

CS (01:24:02):

I've had better experiences, and I've had worse experiences. And at every time company, I've worked at four or five companies, and 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 go far, right?

CS (01:24:21):

I'm not trying to make that sound trite, but it's very true. 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.

CS (01:24:35):

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.

CS (01:24:47):

And if you're in a place that has a toxic relationship, and 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.

EW (01:25:01):

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 some place that they will listen, and you'll be good at it.

CS (01:25:20):

That is a great, much more positive career development focused piece of advice. That's much better. What she said.

EW (01:25:27):

Phillip, do you have any thoughts you'd like to leave us with?

PJ (01:25:31):

Well, Elecia, 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."

PJ (01:25:48):

And we'll get links to those articles added 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.

PJ (01:26:00):

Direct support from our readers is what allows us to set consulting aside and focus our time on producing educational content for the community.

EW (01:26:08):

Our guests have been Chris Svec, Embedded Software Engineering Manager at iRoBOT. At iRobot. At iRobot -

CW (01:26:20):

I believe that they prefer iRobit.

CS (01:26:20):

iRobit.

EW (01:26:23):

- and Phillip 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.

CW (01:26:35):

Thanks, gentlemen.

CS (01:26:37):

Thank you very much. This was a good time.

PJ (01:26:39):

Great time. Thank you.

EW (01:26:40):

Thank you to Christopher for producing and co-hosting. Thank you -

CW (01:26:44):

That's Christopher White, by the way.

EW (01:26:46):

Right.

CW (01:26:46):

Just in case there's anybody confused out there.

EW (01:26:49):

And also Christopher White is my usual co-host and the man I'm married to. Chris Svec 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 for listening.

EW (01:27:07):

You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm. If you like the show, please share it, or consider writing a review.

EW (01:27:17):

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."