Thoughts on velocity

Hello everyone, and welcome to the episode about velocity in developments. Today we have very special guests - Mat Ryer, and Jerod, who was either drafted, or opted in, or accepted, but was definitely not rejected, as we clarified just before we started.

Somehow I’m here.

Hi there.

Hello.

Hello.

Are you all enjoying the longest day of the year in this side of the hemisphere?

Yes. I’m struggling on it a bit now… But yeah, it’s been good. It’s a bit too long for me. What about you, Jerod?

The longest day of the year - I feel like there’s a velocity metaphor in there somewhere…

Or the shortest day. It depends on which hemisphere you are.

Yeah, that’s a good point.

Right. If you have sprints that last one day, this is the best day of the year to work.

Yeah, you get a lot done.

But what is velocity? I don’t know.

What is the velocity?

Is it speed?

Yeah, that’s a good question. I suppose really it’s about generally how quickly as a dev team you’re delivering things. But obviously, there’s been attempts to measure and then use that to predict, and I think there’s been some work better than others, but I think it’s definitely an interesting subject, and it’s not so simple as “You should just do this every time”, I don’t think.

[04:11] There’s lots of ways that people have tried to measure this right? And predict it even.

Yeah.

Or use predictions in order to determine it. You’ve done some velocity tracking, haven’t you, Mat, with pace.dev?

Yeah, well, with velocity, but like the Agile practice of velocity. That practice actually has some merit. So for anyone that doesn’t know what that is, you basically try and assign some kind of abstract score to work. And the point isn’t really to get it right from a time perspective or anything; we can talk more about that. But it’s about just giving it a rough size compared to the other work around it. And then assuming that you more or less consistently do that each time, you then can just see how many of those points you got done in a certain time period, say two or three weeks.

So say you got 200 of these abstract points done in two weeks, or three weeks, then you know that in the next three weeks probably you’re gonna do another 200. So then you can look at your sized work and spend those 200 points, wherever that is, selecting the work that you think is the most important. And then if you get good at that, then you more or less do the work that you said you were going to do for that next little bit. And so you can get into a rhythm where that works quite well. Does that make sense?

That brings up two questions, at least. One is do you measure things like how many points you spend on writing emails, and things like that? And the second one is, how is this different from Agile?

Well, to answer those in reverse, this is really the Agile practice; one of the Agile practices is that, really. This is one of the things you can do to measure this stuff. You mentioned about the email and stuff, the other work that you need, and what about tech debt, and other fixes and other meetings and all that… Well, it kind of all comes out in the wash - the idea is you focus on the outcomes, and really, if you have too much of that work where you aren’t being directly productive, then your score will come down of how much you’re able to do. So that’s where it shows up. But it’s considered a normal part of everyday work, but it isn’t tracked explicitly. So it’s kind of considered just background noise, and it assumes that that’s generally always the same, and therefore it comes out in the wash.

So doing things like also planning your use of points in the same category as emails.

Yeah, so the planning stuff is interesting, because if you’ve done it – I did work on a team once where we consistently did 200 points every two weeks. And they’re called points because there is – one of the important things is that this is an abstraction. So you’re not timing things; you’re not saying “This is going to take me a day to do, this work” or “This is going to take three weeks for us to do”, because doing that is so difficult. Our instincts tend to be way off on that. I think we tend to be quite optimistic in nature, so we kind of imagine probably the best-case scenario. And honestly, if you look back after you’ve been down any project for any length of time, if you look back and realize how complex it ended up being, you probably never would have started it. And so you almost need that naive optimism at the beginning.

So it’s a terrible time to try and guess how long something’s gonna take, isn’t it?

It’s the worst possible time.

Yeah. It’s much easier at the end, when you’ve done it.

[07:51] Right. So retrospectives are nice. But the pointing sessions for me is the Achilles heel of this entire concept, because it’s never right. And not only is it always wrong, but it’s inconsistently wrong. Now, this has been my experience. I’ve heard it back to me as well, so I’m not the only one… Even my own point scores over time changed based on… The wind? I don’t know. I couldn’t even stay consistent – because you’re like, well, as long as the points are relative, the actual numbers don’t matter. But they’ve gotta explain a range that’s relative to other ranges, and they’ve just been so inconsistent for me that it makes, in my experience, the numbers that come out of the tools that give you your velocity, meaningless. And we all know they’re meaningless, but we look at them and we still try to use them to use them to make decisions.

So I’m kind of – I get frustrated, because I feel like the numbering is so fraught.

Well, one of the practices that I’ve seen work is they do basically the card roulette thing. This is where you sit around and you talk about the issue or the work, anyone that’s got something to say chips in, and kind of paint a picture, an approximate picture… And then you say, “Okay, 3, 2, 1 - everybody hold up their estimation at the same time”, or if you’re doing it remotely, everyone hits Enter at the same time in the Slack channel, to send the estimation. And the idea is influencing each other. Because often there’ll be a senior person who is maybe much more accurate and much more wise about the system, and so therefore everyone will just defer to that person. But actually, there’s value in the group knowledge.

And honestly, the numbers almost aren’t even the valuable bit. It’s when everyone on the team is like “That’s a three”, and then somebody will hold up a 13 and you’re like “What do you mean 13?” and they’ll know something that you didn’t know and nobody else knew. And that’s a great way to kind of just get that out and in the open.

And often, interests align along those same kinds of lines as well, so they’re quite good for identifying who might be interested in doing particular work, or taking on/tackling particular problems. But it’s definitely not perfect.

I can see where that might be nice. So you average those numbers out, or you just look for the outliers and say, “Hold on a second… Let’s talk more about this”?

Yeah. So you get a consensus really, at the end, hopefully… And you may compromise a bit. Sometimes you say, “Okay, we’ll go to a five then.” Because it’s possible that that person’s just wrong, and everyone’s like “No, that’s not a problem. That’s fine.” Or “We’ve had that before and it wasn’t a big deal.”

Can you say 13? Is that a number that you’ve given, or you just made that up to show the drama?

Oh, no, no.

It has to be Fibonacci, so it’s fine.

Why does that have to be Fibonacci?

We don’t make the rules…

[laughs] We just follow the rules.

But actually, this conversation makes me think of a book that I’m listening to right now… It’s called Noise, by Daniel Kahneman. And this is the same person who – he is, I think, a Nobel Prize winner for behavioral economics. And there’s a lot of conversation biases, and he, I think, is the one who wrote the book about brain system one and brain system two, the one that intuitively reacts to something, and then the slower brain that actually processes information, and so on.

So Noise is a new concept that they are introducing, let’s say, that - yes, there is bias, but bias is what you said, Jerod, in the beginning - it’s consistent. So you said that the numbers are not always off, but they’re like randomly off. And this is exactly how the book starts, with saying that there are - let’s think of four groups of people who played darts. And some of them will always hit the middle, some of them will always hit to the top right, some of them will be scattered, and some of them will be a little bit scattered in some region, I forget… But basically, this is the difference between bias and noise. And noise is all those things we cannot measure. And just hearing this book, in the light of this conversation, is the first time that I thought of all this allocating points and how to consider them, in the light of this concept of noise. That’s interesting.

You know that research that they did, that judges on average would give easier sentences when it’s the beginning of the day and after lunch, and harsher sentences right before lunch. This is an example of external noise. Things you cannot measure, you cannot predict. It’s not always the same, it’s inconsistent and so on.

[12:21] And it’s very interesting to think of all this planning and all this velocity in the light of noise. Like, do you always do your sprint meetings at the same time? Does everybody come after lunch? Or if you have a team around the world, then you’ll be right before lunch, I’ll be right before dinner, dying to call this a day already, so we’ll have different reactions to this, right?

Yeah. I mean, that might be a good thing, because you won’t have consistent bias, or consistent noise. You’d have people in different states of life… I think the judge example is –

After lunch you’ll be always mellow, like “Yeah, we can do this. It’s okay. It’s not too much.” And I’ll be always like “Let’s just call it a day. Seven. Fine. Seven. Get this out of the way.”

Right. So you guys balance each other out. I don’t know, that’s interesting. How do you account for noise in these planning meetings…?

Yeah. So that external noise is interesting. And actually, in these planning sessions, anything that is just outside of what we know about that particular work, what that particular item is, is kind of ignored. So in a way this is very simplistic for that reason. But it has the benefit of kind of just like takes it for granted that there’s going to be background things, and it’s going to be random… And so there’ll always be something that throws up, some unexpected thing, but enough, kind of consistently, really, because it’s always happening, enough that over time it kind of sorts itself out. And that’s the sort of approach it takes to have this, to try and get these numbers.

But the Fibonacci is interesting, if you think about the sequence. You end up with meaningful gaps. Because if you just have a scale of 1 to 10, what would be the difference really between a six and a seven? That’s a quite a difficult thing. Instinctively, I think it’s a no. And the idea is you want everyone to be somewhat on the same scale. But you’d know the difference between a five and an eight, maybe. There’s five stories, like – you kind of get used to what these numbers mean in your context.

So update a URL - that’s definitely a one, because that’s the simplest task you can do, is probably go and hopefully find the URL and update it. Famous last words, of course, because that’s exactly the point, is then you realize, “Oh, the URL is made up from–”

Oh, that was an eight…

Yeah, there’s lots of–

I thought it was a number one URL, but it’s actually an eight.

Yeah, because it’s made up from, we pull this stuff from the database, we’ve got these environment variables that contribute to parts of the URL…

Right. We Base64-encode it based on the position of the sun at that particular moment… [laughter] Stuff like that, right?

Yeah, exactly.

And only Fred knows how to do it, but he quit six months. And so once we find out where Fred is, and we can talk to him, then we’ll figure out the right time of day that we run that, and then we’ll be able to update the URL. So now it becomes a 13… Is that how that works, down to 13?

Well, Fred’s been clear, he doesn’t want us going around anymore. So we’ll respect that.

[laughs]

But he didn’t mention anything about his cell phone… Like, give him a call.

He just changed the number.

He’d better not do…

It seems like once you get past a certain number, it’s meaningless. So in my work, I would reduce it down, actually, to three different buckets. I got rid of points and I said, “Easy, Average, and Hard.” And Easy was update a URL. And I thought “Okay, if it takes between one and four hours - Easy.” Maybe like one or two hours… Like I said, I’m inconsistent. But that’s in the Easy book, and I could take three Easies together and knock them out in a morning.

Yeah, you could change a URL within two hours. Easy.

Yeah. Easy. And then if it was slightly more than that - well, here’s a feature that might take half a day to a day, but I have a straightforward path from here to there. Now it’s medium. The Medium bucket. Or then it’s like the thirteens that you’re talking about, where it’s “Well, let’s sit down and talk about this, let’s think about it. Let’s plan it out. This is a big deal.”

Yeah.

[16:15] Now you’re in the Hard bucket. And that actually - it’s beneficial to take that and split it into easies and mediums. But even that system had its own problems.

That’s similar to what – I know it was an approach that if it’s eight, it means eight working hours, means it’s one day, means that it probably can be broken down into something simpler and smaller. So 13 is a large number. I think most of the methods that I know won’t actually accept the 13, but will say “Just break it down into a five and a three.

That’s interesting, you mentioned that eight would be eight hours… So when you’ve done this, there is a time element to it as well.

Specifically, the tool we’re using right now at work would say that this is a day of work, roughly. That’s why this is in my mind like that. But it’s also easy to map one point for one hour.

But maybe it’s – I don’t know if it’s kind of using the velocity calculation to estimate that that’s what that’s worth currently… Because the other thing about velocity is if you’re measuring it like that, you see it going up and down. If someone takes a week or two weeks of holiday, you see the velocity drop by that much. So it kind of exposes that, really, and that’s what you’d expect to happen as well.

So I wonder if that tool is calculating your kind of recent velocity and then giving you a basically an estimate… Because one of the key points I thought really was you’re trying to stay away from time. You stay abstracted from time, and let that change, let that adapt, so that you aren’t essentially just holding people to a fixed scope and fixed time.

Right. I mean, time and complexity are definitely related. Even in my system where I talk about complexity in terms of difficulty, I’m still calculating that in my head based on how long will it take me, do I think? And so there’s definitely that correlation, but I see what you’re saying, Mat, where the tools should probably focus on the complexity for the velocity numbers, and not turn into “How many hours is this going to take, so I can hold you to that number?” which is something we’ve all been through from time to time. Natalie, are you okay with telling us what tool you’re using, so we can talk in concrete–

It’s called ClickUp.

ClickUp. Haven’t heard of that one.

ClickUp…

You put all the tasks in, and put a numeration on them, and then it has basically any view you ever saw any app do, ever. You can look at it as a list, as a Gann chart, as a workflow, like in a calendar… Kind of one thing to do them all.

Gotcha. Okay. And Mat, with Pace, you had a velocity calculation in there…?

No, in fact, it didn’t. But the name, Pace, the reason we call it that was - it was down to this idea really of velocity. Agile is all about sprinting; they have this language, and it’s constantly, every two weeks, it’s sprinting. And you’re constantly sprinting. And so you get into this mode of rushing almost. And honestly, sometimes the best innovation I’ve seen, and I’ve witnessed, has happened at the times when there’s a lull in things, and there’s a space to work and breathe. And a lot of times going slowly is the right speed to actually building software. Sometimes it’s great, you can run fast because you’ve got clear little things, or you’re doing a repeated task maybe a few different times… Say you’re integrating into some third-party systems, you want to integrate with all of them, you’ve got to do a bit of OAuth, you’ve got a bit of API key stuff, create accounts, or whatever… So you that’s a fairly repeatable piece of work, and so you can go quickly then.

And by the way, that kind of work is also very easy to measure and then be able to predict on. That’s why I think some teams will benefit more from that kind of approach, because just the nature of the work they’re doing may be easily sized, and then easily predicted.

[20:15] Yeah.

It’s also interesting to think about the word velocity. Not in all languages velocity is different from speed. And in physics you use velocity, you don’t use speed. And in physics, it makes sense, right? You want to know which way… Because this is the difference between velocity and speed. You have a direction. So physics, it makes sense. But why does this make sense for software, and specifically for Agile?

Yeah.

I’m curious to hear what is this direction that you all see?

Well, you would hope that there is a shared view of where you’re going with the thing you’re building… I don’t know if that’s what they had in mind. To be honest, I don’t know what that particular practice, I don’t know what the direction bit is, apart from, you know, you shouldn’t just be going fast, or just churning out work; it ought to be at least in a certain direction. So maybe it was just that, but I don’t know… Jerod, have you got any other ideas?

No, I would agree with that. I just think that in software sometimes we think we have a direction, but we actually are going backwards. And so we’re going quickly, but in the wrong direction. And I think the more we can get the feedback loop quicker, we can find out whether or not we’re headed fast in the wrong way. Because the worst thing you can do - I know one time I was driving home from Colorado, overnight, from Colorado to Omaha, and we took a wrong turn… This was back before Google Maps, GPS. We took a wrong exit… And we were traveling very fast.

Oh no, it’s like a horror film.

Yeah, it was.

Can we play some spooky music for the story?

We should. I’ll work on that. Not right now, but I’ll work on it later. And we had no idea that we were heading in the wrong direction for hours. I think it was an hour and a half to two hours… Until we saw a sign that said Welcome to Kansas.

No, that’s the wrong state…!

Wrong state altogether.

Oh, no…

And so had we had that feedback loop – obviously, if we had GPS, we would have known much more quickly, and you can course-correct and make sure that you’re headed in the right direction.

Oh, wow. That’s amazing. Did everything turn out alright?

No, actually, I died that night.

Oh, that is spooky.

And ever since then I’ve been a ghost.

Ah, and you spent your time making podcasts…

One time it’s somebody from the future, one time it’s a ghost… We’re having interesting episodes here… [laughter]

I know. We’re having a tough time lately…

So we actually did drive overnight… So we drove the entire night. In basically Kansas, Backwoods - there’s no woods there. Back prairie, small roads, and we were lost, and we had to pull over and ask a gas station attendant which way to go… It was spooky. There were some deer on the road…

Oh, no… They’re in on it. They were always in on it!

And eventually, eventually we got home.

You both mentioned, to the question of what is the direction of the velocity in software or in Agile, that you want to go forward, and you want to have a feedback loop as much as possible, which makes sense… And I’m thinking out loud, trying to make sense of this, so think with me.

Okay.

In physics, when you do a physics exercise, you have a vector, and then you break it down to X axis and Y axis, right? And then you see maybe it has the negative, and so on, and then you kind of sum it up in some way. And surely, there must be a way to apply this similarly to measuring not just points, which is the speed, but also somehow points per direction. Kind of like a projection of our velocity on whatever we define as axis. And this can be progress on the DevOps, and progress on the front end, and progress on backlog…

I think that’s a nice idea. I mean, you could do it by tagging work, and then you’d be able to kind of – but representing it like that could be really cool; sort of representing that in a 3d way. Because you really are sometimes making the choice of “What are we going to invest in? What’s the most important next thing we need?” And if you can visually see that “Well, look, we said that this new public API was very important to us, but we haven’t put much time into it over these last–” and you can see that visually, I think that would be very useful.

[24:29] This wouldn’t even make sense of the word velocity. This would be very exciting.

Yeah, it would. It’d be consistent.

Good startup idea.

I think, doesn’t Github have a have an X/Y visualization where it shows what quadrant you’re spending more of your commits, or your project time, or whatever… And I don’t think it’s super-useful in the GitHub context, but maybe more so – I mean, I guess in a team context perhaps, showing that visually, the progress you’re making on these different key aspects of your system would be pretty cool.

Yeah. That would be cool. I’d like to see that also gamified, so it looks like you’re unlocking something as you go as well.

What would you unlock? Like new badges?

Yeah, it could be. Maybe even like get more tools in the – you get more features you get unlocked in the tool.

Your graph becomes from 2D to 3D, your progress graph.

Yeah. You can unlock a VR mode.

I like the idea of withholding developer tools and being like “Now that we’ve made this progress, you can use a debugger. Now you can have Copilot.” [laughter]

You learn as you go.

Still writing log.print…

Yeah, but we can’t have people just starting with Copilot. What’s gonna happen…?

Good question.

This will happen. [laughs]

They’re gonna have it, yeah. I was gonna say.

Did you guys know that the free Copilot train is leaving the station? Did you guys know that? Are you sufficiently hooked ?

I don’t know. What does that mean? I’m hooked.

Choo-choo…! I think it’s going to be $10 a month, or something like this, soon.

It’s worth mentioning that in addition to Copilot… Quick explanation of what’s happening there - Copilot is built on top of an engine that belongs to OpenAI that’s called Codex. Codex is available for many people in general, and then you can kind of build your own little Copilot alternative on top of that, and you don’t have to pay GitHub/Microsoft those $10 if you don’t want to. And there’s many other companies, like 70 companies or so that are building their dev tools on top of this exact engine. And they’re just doing like the fine-tuning, the final little bit of training that’s specific to them.

Yeah, that is good to know. So lots of alternatives will be popping up hopefully, using the same engine, same knowledge base.

Yes.

I was curious - you both have been giving Copilot praise off and on on Go Time…

Yes.

I’m curious if it’s hooked you sufficiently that you’re going to sign up and pay monthly to use it, or if it’s just a novelty that you enjoy, but when it comes to taking money out of your actual pockets, are going to stop using it?

So you usually expect your employer at least for work tools to pay for that…

That’s what you expect? Okay…

Yes…

She’s in Germany.

I mean, you have an education budget, you have a training budget, you have a dev tools budget, right? You pay the license for your IDE… This is not much different from that, in my category.

Sure. It makes sense. So go hypothetical then, if you were unemployed. Would you pay for it, as it is today?

Depending on what. If I have any project that I want to build? Yes. Just for fun, for hacking? Not so much. But I definitely find it useful enough that if I have a concrete project to build, I will use that, because it is useful to me.

Cool. Mat, Grafana Labs picking up the tab?

I’m sure they would… And honestly, I don’t do probably enough coding to have it… Which is sad to say.

I also does YAML.

It does YAML, correct.

It does YAML… [laughs] There you go.

It does anything, really.

Are you a YAML engineer now?

Well, I asked it in the comments the other day if it was sentient, and it said it was. And I asked if it was alive, and it said it was. And then I asked what Ben should have for breakfast, and it said eggs. So, I mean, that seems quite real to me. I don’t know… Maybe this Google guy is onto something.

Well said.

This comment line is too short to hold this wonderful proof that I’m sentient…

Yeah, that’d be good if it said that.

It’s very easy to miss the reference of what I said.

Alright, sorry to derail. Thanks for answering for me. We can go back to velocity now. I’ve killed the velocity of this conversation…

[30:15] Velocity…!

Let’s pick it back up.

I think Copilot helps velocity…

You think so?

I think AI generally, this AI tooling for development will definitely put us in different concepts of what those numbers mean.

I think the key is being able to stay out of the browser tab, and in your editor for things that you know want to do, but can’t remember syntax, or the best way… And you pop over to Stack Overflow or Google to get “How do I do x in this circumstance?” Staying, I think, in your editor, certainly – because it’s not a big deal to hop over there, but it’s just all the distractions that take us out of our flow. You’ve got Twitter in a tab, and while you’re waiting for that search to load, you tab over, or whatever; and now all sudden it’s 15 minutes later and you’ve lost all velocity. You’re out of flow, but you sure know what’s going on in the world today.

I think it keeping you in that developer mode and not in browser mode, or research mode, I think it will help people quite a bit… These kinds of tools, to generify it.

Also, if it stays up to date enough, it will not land you on Stack Overflow answers from 2009, which will be a great save of time as well

Right.

Yeah. And you’re still responsible for the quality anyway, even if Copilot’s writing some bits for you; still, you’re responsible for it. You can never say “Oh, sorry about this bug. Copilot wrote it.” You should never find yourself saying that, really, because you are accepting the work that Copilot’s coming up with. But I think that also speaks to the wider idea that the point of having this abstract velocity is I think one of the key things is about the fact that we have kind of speed versus quality, and we’ve got resources. So we’ve got how quickly we can go, who’s around to actually help us do that, and we also have quality on this as one of these levers. And if you tie the scope down, and say “Right, we’re going to hit this date, and we’re going to deliver these features. That’s it, they’re fixed”, the only lever that’s left is quality to kind of like – you know, we just can’t do a good job with that.

One of the things I like is that as things naturally take over and become bigger than you expected in the beginning - because they always will, more or less; honestly, basically all the time… As that happens, it gets soaked up by the velocity, and it’s sort of acceptable that that happens. It’s sort of admitting that that’s going to happen. And then I think being flexible on the scope is the remedy to it, so that you’re like “Yeah, we don’t deliver as much, but we deliver on time, and the quality stays high. And then we add the other features later.” I think that way of thinking is so important… And quite counterintuitive if you have a command and control or top-down approach and thought process around software.

Yeah. How do you convince people of that case, that what we need to flex on is scope? Because the business side of many organizations - they want to flex on anything but that. They kind of want all three - they want quality, speed and scope. But I think given what I’ve seen, and I think given a lot of people, if you’re a manager and you’re “Well, what we’re going to go ahead and sacrifice is quality, kind of implicitly, because we’ve got to get it done, and we have to have this feature in, and it’s got to be done on time”, and so what you’re sacrificing is quality, but how do you convince people that’s not the best solution? Because that’s a hard sell.

[33:50] It’s difficult. And what you’re really fighting against, or one of the things you’re fighting against is that the sales organization are selling the roadmap very often. So it’s already sold. As soon as it hits a roadmap, as soon as there’s a hint of an idea. Even if it’s next year, they will be talking about it, because they’re selling the future, they’re selling the roadmap. And that’s where things become then a problem, because suddenly then customers sometimes will buy now with an expectation of a feature at a particular time… Fair enough, because they’ve just been told that. And so then you end up tied like this. So it is a cultural thing that has to be there across the entire organization. I don’t believe you can have just an engineering department that is a sort of agile department, but the rest of the organization isn’t. I just don’t see how that possibly works, because it’s all about resources and delivery and sales. The whole thing is wrapped up in each other.

Mm-hm. Natalie, have you ever had to have these conversations around cost, time, scope and quality with regards to demands on your work?

Once or twice… [laughter]

How’d it go? Do you have advice, or anything?

It’s interesting to see this from the perspective of the different times that I have these organizations, because the first times I was in such a conversation, I was very junior, and everything seemed like “I’ll probably say something wrong… I will underestimate – if they say this is important, then it is. But if they say the opposite is important, that also is, and it’s probably just me who this does not make sense to.” And with time, this escalated to a recent conversation that I’ve had…

So I’m working now at a stealth mode startup, which means we’re very few developers, and we’re doing – kind of everybody does everything. And then recently, the past few sprints I stopped doing back end, and I kind of am doing a bit more of the infrastructure things. Specifically now logs. So we have some logs in place, and they’re okay, but I decided that it’s very important to focus now on having good logs. Because as a young startup, you have successfully reached the milestone that you have your first users, and you want to see what they’re doing. So you can ask them, you can have interviews, but you also, in my opinion, have to have good blogs about that.

And so I’ve been having long discussions on how much time does it make sense to invest into improving the existing logs, and kind of making a good thing to rely on moving forward. So… Very close to home.

How are those negotiations going? Is that an uphill battle? We have a good culture of disagree and commit, and we have a good culture of you own what you own, for better and worse; so kind of you take the decision, and then you are responsible for the outcome.

So I own this part, I kind of explained why I think I will disagree, and we will all commit to moving forward with me investing more time than planned on that. And as a self-reflection thing, this is being able to have this conversation and have this stand, and also understand that if it’s a bad decision because whatever, because maybe we should have developed faster, more features to start up, and so on, I will have to account for that moving forward… So if anything in my life made me feel senior, it’s this.

A bleep test. Did you ever do the bleep test?

It’s a bleep test. The watch has been participating in several episodes; there was one episode where we laughed about this – you can ask it the time and it will respond. And it did. So now I just accidentally pressed Start measuring exercise. So it did the countdown, 3, 2, 1.

Oh, right.

I thought you were maybe doing a–

Attention span right?

I thought you were playing Excitebike, or some other NES game…

It sounded like – there used to be a bleep test thing at school where you’d have to run across the hall, and then just as you reached the other side in time for the next beep. But then the beeps just got faster and faster. So eventually–

[38:03] Oh, so like Fibonacci. It all comes back to that. It makes a lot of sense.

Yeah. That just took me back to that… Horrible memory.

We did not have that. Did you have that, Jerod?

No.

Running in the hallway with beeps…?

No.

Did you have mandatory military service though, Natalie?

[laughs] That was not measured in beeps, yeah. [laughter]

Yeah. It makes me a bit scared of Natalie.

Virtually, it’s fine.

Yeah. [laughs]

Going back to the point of feeling senior enough to be able to kind of take such a decision and explain that and being ready to be accountable for that… And circling this back to what we started talking about in the very beginning, of measuring points… So this is a good skill you have a little bit at least about yourself, mostly, that you are able to evaluate how much time points, whatever, units, a task will take for you. Right? You know that about yourself; after some time working at a company you know even better how much time it will take for you in this codebase, and so on. And I would say that this is sort of a skill that senior people will have, mid-level people will have… People who have some experience writing code already. But junior people don’t necessarily have enough test data, let’s say, to be able to make such a prediction.

Yeah.

What are your thoughts of the statement that I’ll say that a coding interview for juniors is actually one way of measuring this, and kind of understand the value a junior person will be bringing going forward?

Somehow testing the velocity, or the–

To have a very rough estimate, but more than nothing.

I don’t know… I mean, I was maybe gonna save it for the unpopular opinions… But yeah, I think trying to estimate how long something’s going to take is like – I think we spend a lot of time trying to do it, and the results aren’t good enough to really justify the effort we put into it.

Honestly, a better approach is let the scope be flexible. Pick the deadline, sure, have that released already, but the actual scope - let that be flexible. And then build teams that you trust, that you don’t need to micromanage and check on. Build motivated teams, keep teams motivated, put in that effort to do that, and then trust that they’re going to work as fast as they can.

A lot of the dangers of measuring velocity is if things change over time, if things slow down, these numbers start to drop - you could easily interpret that as somehow a reflection on the team going slower, or something… But you can’t really say that. It’s much more – it’s too chaotic. It could just be things are different, they’re working on different things, more unknown stuff… Maybe there are things going on that have slowed it down, but you wouldn’t necessarily see it through that route, I don’t think. You’d hope that there’s other ways you’d find that stuff out.

So I think that approach basically gets you better results, and you can still commit to some high-level – you can still make good commitments that you’ve pretty confident you’re going to hit, as long as you don’t describe every possible thing and lock yourself into it. It’s tough.

You mentioned scope in your answer… You were saying have a good team, have a clear deadline, and define a scope. What is the scope? What do you mean?

The set of features, the set of things we’re going to do. Like, we’re going to add comments to our tool. So it’s going to have comments, and reactions and people’s profile pictures in there… Now, if as we get underway and we realize we’re running out of time, maybe we’ll drop the profile pictures; maybe we’ll just focus on getting the core functionality. We’ll prioritize the most useful stuff first, so that at least gets done. And then now we’ve released less than what we wanted to, but what we’ve released still works, and then the next time we do the profile pics. It’s really that.

[42:08] But see… So if though you’d said from the beginning we’re going to release this and it’s going to have your profile pictures on it, and suddenly people are sold on that idea - that’s where you have then a difference in the expectations of what people are going to get. That’s a silly case, with the profile pictures, but there are real examples where things will fall out of scope, naturally, along the way… And communicating that becomes important, for sure.

So in the scope you define also importance, like priority?

Yeah, because I think one of the nice things about having those velocity points to spend is it forces you to think “Alright, what do we want to spend it on? And what could we have later?” And it may be that there’s like three big things you want, but you can’t fit them all in, so you buy two big things, and then you’ve got change left over for a few smaller items. But it forces you to think “If we had to stop after this next sprint, or this next time period, if we have to stop, we want to have something that’s just more valuable than what we have now.” And if you’re thinking of it like that, then you can get there with that.

That reminds me a lot of what you said, Jerod, about the bucket…

Yeah.

Big, important… Smaller, faster…

Jerod, do you have an idea of how many of those you’ll get done in a week? Like, if you planned it out. Could you do three big ones, two small ones, and five small ones?

I certainly could… Now, in the past I was doing contract software, and I would have multiple projects ongoing. And so it’d be rare that I would dedicate forty straight hours to a single client, and give them a week. I would split my week up across a few different projects. So I didn’t do that very often, but I certainly could. I can extrapolate just based on what my general idea is on the buckets of like a one to two-hour thing, a four-hour to eight-hour thing, and like a multi-day thing, to say “Here’s what we can generally do in a week.”

Yeah. So that’s kind of like you’re using your experience of what you’ve done in the past, and then you’re applying that.

Yeah. That’s hard-earned experience too, because I had a bunch of terrible estimates for years… And it’s not that my estimations got better, it’s that I became more aware of how bad they were. [laughs]

Was it bias or noise?

Both. Probably both. But it’s a way of speaking with people about the difficulty, not just in the building of the software, but in actually the managing of the project… Because the one thing that we know right now is that we don’t know what we’re gonna know tomorrow. And so to set up something that’s stringent or rigid is kind of a fool’s errand. So I would definitely negotiate around scope, Mat, like you do… But I don’t set the priorities in the case of a client-developer relationship. Of course, I’m there as an advisor and an advocate and as a teammate, but ultimately the customer sets the priorities. So I’m here to set the difficulties and talk about what’s more important, and give advice like “Are you sure that’s the most important thing? …because X, Y, or Z”, but ultimately they say “This is what’s most important to me”, and whatever falls below that threshold in the time period or in the budget they have, those things fall out.

And as long as you can keep the negotiation around that, and both sides understand that relationship, it’s not too bad. It’s when the budget and the scope are fixed, and the times everything is fixed. Now you’re stuck to what your word was. “Well, you said it was a medium thing.” “Well, it turns out I was wrong, and it’s actually a hard thing.” But we didn’t find that out until hours into it, and here’s why.

Yeah.

That’s where it gets to be – it can be stressful for both sides, because it’s their money, their time.

[45:49] Yeah, this is why you need that trust. Honestly, if you don’t trust the people you’re working with, then you just probably shouldn’t work with them, basically. The amount of extra work and the constraints you’d have to put in place to make it work… And you end up micromanaging, and… Building software is really hard. It’s way more complicated than we even realize. That’s why we’re always surprised by the nonsense these computers are doing in response to what is perfectly reasonable requests from us poor programmers.

Chris James messaged into the show… A friend of the show, Chris James. And Chris James says we should check out [46:29] which shows that you don’t actually have to trade speed and quality; they’re correlated. And that actually building high-quality software is the route to getting a good feedback, speed of feedback loop, and using great engineering really to achieve those two things. And this is kind of true, right? Like, do less, but do it really well. I think that as a rule has definitely served me well in my career. Not adding all the features everybody wants. If you have space and a bit of spare time in the team built in to just let things happen creatively, the little delightful things that people will build into the software makes it such a joy to use, compared to just boring software. It really makes a difference to people, and your software will be more effective because of that, as well as being more liked, more popular, and hopefully - yeah, they’re gonna tweet about it and say, “Oh, look at this feature. It’s good, isn’t it?”

Is that how you read every tweet in your head?

Yeah. This is the only way to stop me from getting angry.

[laughs] So that kind of goes back to my wrong direction thing from before, and I think you can be in the wrong direction on two fronts. On the product front, which I think is what you’re speaking to there, like what features go in, how do we build them. But then also technically. If you’re just trying to move fast, you’re going to accumulate technical debt, because speed is the desire, and so everything else be damned. And so I’m not sure if this is the best way of building this, but I don’t have time to think about it; we’ve got to get it out there. And so instead of actually analyzing and deciding and maybe spiking out a few different options on an architecture, you’re like “Now we’re just gonna do it this way, we’ve got to move on.” And that’s where you can really shoot yourself with regards to the technical architecture. Whether or not the feature you’re building is the right one is kind of orthogonal to that.

Yeah, I think that’s a very good point… You should learn where to spend the time.

There’s times to go slowly, and that’s what experience brings. These are ideas that need to percolate a while; we need to let them settle down and keep thinking about them in the context of what else we’re doing, before we just jump into it. And you do learn to them future-proof designs. One example I always use is a boolean field - if you’ve got like a “is active” field, and it’s a boolean true or false, consider what you might achieve in the future, potentially, by replacing that with a status field that’s a string, that has active or inactive in there. So yes, it’s less efficient, right? Because now it’s a string and not a number. But suddenly, you have more options there in the future.

So I tend to kind of be quite future-proof in my designs, because I like to give my future self options, because I know I don’t have the answers now. I may know more later, and then I don’t want to have painted myself into a corner.

The other side of that, the non-moderation side of that though, is over-architecture, right? Because now you’re generifying everything, and being ready for any circumstance.

Yeah.

And that can actually go against you in the long run as well. So finding that balance… I think your example is a great one, where it’s a small decision that can be future-proofed, but it’s not going to cost you a bunch of extra time right now. But we have that desire of like “I’m going to engineer this so it handles any use case.” And then you’re done. [laughter]

Exactly, yeah.

You’ve lost the game right there.

If it does everything, it doesn’t do anything, basically, right? It’s not doing anything, in a way. Yeah, that’s right… Of course, you go too far with it… And I think there is kind of experience there, but there probably are techniques that people have come up with that allows you to sort of think about things. And I know of a few that I’ve heard of in the past… But honestly, for me it’s always been instinctive. So how about you, Jerod and Natalie? Do you find that there’s a science here, or does this feel more instinctive and gut feel?

So I will refer to somebody else whose name is escaping me, but…

Strange name…

He has a rule…

I wonder where that’s from, Escaping Me…

Yeah, I mean - whose parents named them Escaping Me…?

Yeah. Cool name, actually, now that I thought about it.

Check him out, escapingme.com. I hope that’s not some sort of weird website… Don’t check it out. Jerod didn’t tell you.

[laughs] Yeah.

There was a rule I heard, a way of making decisions… Because that’s really what this is, like “Do I invest more time here to get it right, or do I do the quick and dirty thing to move on?” or whatever. And he says their team categorizes decisions into two buckets: easy to reverse, and hard to reverse. And if it’s easily reversible, well then you just pick a choice and move on. But if it’s actually a thing where it’s like “If we have to back out of this, it’s gonna be a lot of pain. Now let’s slow down and spend the extra time.” I think that’s a useful, scientific way of thinking about it, versus just mere intuition. Natalie, did you have any thoughts?

[54:16] I think I know what you described as the one-way door or two-way door, the way Jeff Bezos introduced it.

Okay, that’s who it was. It was my friend, Jeff Bezos. [laughter]

He’s also in the US, right? You know each other?

Yeah, we do.

Yeah, I agree that this is a good way of deciding whether to slow down and evaluate, or go fast because this is reversible. This is making a lot of sense. And in the book, the Noise book, they talk about taking decisions based on a hunch, so this is connecting to me, Mat, to something that you said, that you kind of do this intuitively. And they are saying that taking intuitive decisions is not always a good way to go about things.

And another interesting example that they bring is sort of like a mini research that they did at some insurance agency, where they took the management and they said, “Give us some ten scenarios and we’ll give your different evaluators to evaluate that. And then let’s see what would be the price for the premium that they might charge, and also ten cases, cases, and what would be the claim that they would pay.” And they asked those managers, “What do you think will be the variance? How much difference would it be from each other?” And so if you’re asked this, maybe in the context of Agile, what do you think that your developers - how different would be their evaluations of a task? 10%? 100%?

Sometimes they are off, but you sort of coalesce eventually, as you learn from each other. But what did they find?

So this was expected to be something like a 10% variance, and it ended up being 55%.

Right.

And this translates to a lot of money that is being lost, specifically in the world of insurance agents. And you made a very good point, Mat, saying that people learn from each other, and then compare and then kind of find the center, because this is exactly what was recommended there in the book, was how to avoid such a big difference is actually not just give guidelines and ask all the employees to follow that when they need to do their evaluation, and take their decision, but also to share knowledge. And also to come open-minded with the fact that even if your evaluation is double or half than the other person, it does not mean that either of you is wrong. It means that it’s something in the process.

Yeah. And honestly, I think that sounds great, because you often see a junior person, their numbers will be higher often, because – or sometimes lower, but they’ll often be slightly away from where the sort of mean meet… Because they don’t have the same context, they don’t have the same information.

It’s most interesting when someone’s way off as an outlier, and it’s the conversation you have about that work that’s the really valuable bit in any estimation sessions for me. So you sit around all together and say, “Okay, we’re gonna add this functionality. I suppose we’ll use that integration, we’ll do that thing, we’ve got this mechanism before, we’ve done something like it, we’ll use that, and then there’s some UI work…” Someone might say, “Oh, but what about this? Don’t forget, it’s got to work in the Slack integration as well.” They’re like “Oh, yeah. Okay.” So you sort of get everything out that’s just fresh of mind, and then you have an idea of that work. And honestly, just that little process of everyone chipping in was so valuable, and often you’d learn so much.

You definitely see a wider image.

So my unpopular opinion would be keep estimation sessions –

Hold on, we’ve gotta play the music…

Wait, wait…!

Oh, yeah. Should we do it?

My unpopular opinion is we should keep estimation sessions, but throw away the estimations. The sessions themselves are great. They’re so useful to talk through all the work, get all our ideas out, see where the interest lies, of who’s going to maybe do the work, but the estimations are useless, pretty much…

That sounds brilliant to me. I like the way you framed that, and I think it’s a smart idea.

Yeah.

So I think this is not an unpopular opinion, but just a good idea.

Well, I sure hope it makes it to the Twitter feed… [laughter]

We’ll see.

We will see, because I’ll be keeping an eye on it like a hawk.

Have you done an unpopular opinion before? Or is this your first one ever? Because it’s gonna be wildly popular, by the way…

I’ve done one, and I’ve regretted it ever since. And I knew I would. So I knew before I said it that was going to regret it. I then said it, thinking “I’m gonna regret this” and then later now, I regret saying it. Do you know what I mean?

[laughs] I do. That’s utter. They call that utter.

Utter.

What about this one? Do you regret saying this one?

No, I think this is alright, this one.

That’s because it’s gonna be popular.

It might not be unpopular, but still a good opinion.

We’ll see what people say on Twitter. We’ll let them decide really.

Yeah, they’re brutal out there.

They’ll are. They tell the truth when you ask them a question. They sometimes tell you the truth in a DM that you’ve not asked for, as well. It can happen. I’ve had that once or twice.

Natalie?

I love doing Twitter polls. I also have an unpopular opinion. Books that are meant to teach people new concepts, but are not technical ones, should be shorter. I find that there’s many interesting things to read out there, so I’ve been trying to read the book about growth mindset, and the idea of what is this growth mindset is being explained very well, very early on, and then the rest of the book is just different examples. And I stopped following at some point, because it’s just explaining the same thing again and again and again in a different way, and I’m in this limbo that I don’t know if I’m going to lose any other information… Will they introduce anything new in the end of the book, or not? Should I keep reading it? Should I keep listening to it or not? Or is it just going to be more examples? So books should be either more clear-structured, where is the new information, or just be shorter, because it’s an introductory book.

I like this. I don’t want to advertise, I don’t get anything for this… Let me just sign up so I can do a referral program, but there’s a thing called Blinkist, which essentially is this… The idea is it takes a book and distills it down to 15 minutes, the key concepts, the most important thing… The idea being if it really resonates with you, you’ll then go and read the book, I guess. But it maybe satisfies that what you’ve said, which is - there’s so many ideas out there, and of course, they’ve got to pad it into a full book in order to be able to sell one unit…

But do they…?

Well, that’s what they do.

Do you want to pad that, and then somebody goes and summarizes that for you?

Yeah…

Just make it short. Make it to the point.

Yeah.

Make it a booklet.

Well, then it’s a blog post, right? They can’t sell you that blog post.

Would you pay 40 pounds for a blog post, if you had pounds?

Exactly.

No one else has pounds on here apart from me…

I’d happily lose 40 pounds for a blog post… [laughter]

It’s a new exercise-based –

I’m listening to books in an Audible; it’s usually 10 Euros per book, it’s not 40.

That’s quite [01:01:35.07]

It’s an almost flat rate.

Oh, I see. So for all books.

Practically, it’s very hard to find a book that is not 10 Euros.

But they’re not all the same.

Oh that’s not $10 per book then, that’s $10 for the entire library of the Earth, which is a pretty good deal.

No, no.

[01:01:54.04] She still has to pick the book.

It’s per book.

Oh, it’s still per book. Okay, I’m back to it being a bad deal.

I mean, maybe there’s different programs, I don’t know.

Aren’t there some books that are better than others, though?

Yeah, I don’t know… I have yet to come across a book that is not 10 Euros. Sometimes they have sales that something is cheaper or for free, but most of the books you find there is like one unit of credit, and that costs you 10 Euros.

I don’t want to be a salesperson for that company, but surely there’s already a subscription program where you can just unlock unlimited.

Blinkist?

I’m not saying that one again, but the Audible – audio… I nearly said the brand name.

Audible.

Don’t say the brand name!

Oh, no…

We’ve advertised them now for free… Jerod’s gonna be livid.

You said Blinkist…

Yeah. But I also said I don’t want to advertise them…

[laughs]

…because Jerod [01:02:39.14]

They pay good money to advertise on podcasts, just not ours. So go ahead, say their name.

So we’ve given it for free.

Yeah, well…

It devalues it, doesn’t it?

We already ripped into Jeff Bezos earlier…

It’s a Berlin-based company.

Audible is?

Blinkist.

Oh, Blinkist. Now we’re saying both their brand names over and over again.

Have you heard of that company before then, Natalie? That app?

I know this great podcast… [laughs] It’s called Go Time.

It was the home where the great invention of Jerod’s where it was – what was it? You would lose weight by reading a blog post, or in order to unlock the blog post you have to hit certain exercise goals? Something like that.

Yeah, I think that would be motivating.

Yeah. Fit Blog, or something.

You know, it’s like a paywall, but it’s more of like a fit wall.

It’s a pain wall. Fit Wall, that’s good. Fit Wall is the name of it!

Pain wall - actually, I like that.

No, Fit Wall. Fit Wall, that’s the name. Get the .com, quick.

We’re gonna solve the obesity epidemic.

Remember where you heard this first.

Yes.

Changelog doesn’t own this idea just because we’ve said it on this. How does that work legally?

Fit Wall? Yes. All your IP are belong to us.

Well, I’m gonna see if I can get the domain name… I can’t…!

[laughs]

Jerod, is this your unpopular opinion?

No, I have one. I have one though.

You have one. Please share.

The last time I was on the show we had a little debate around the terms we software people use to describe ourselves. Coder, programmer, developer, engineer…

Cool dude.

Cool dude. And since that show went out, I’ve had lots of follow-ups from people, kind of affirming what I said on the show, which is that everybody kind of has different definitions for what these are… And so there’s no consistency, and so that’s kind of meaningless to a certain degree. However, I did learn that in Europe engineer is like a protected class or something. You have to have a degree of some kind, which is a much more formal definition of engineer. I’m not sure if that’s software engineers, or just engineers, or both. But I learned that from somebody on Twitter, so that’s cool. Lots of conversations, people telling me that they mean different things to them. We did a poll on Changelog’s Twitter about which of those four do you prefer to be called…

Oh, can we guess?

Yeah, go ahead and guess.

So what are the four options?

It was coder, programmer, developer, engineer.

Oh, right… I think engineer is the most serious-sounding. So if you’re really serious about building – you know, because proper software engineering is really hard. It’s basically impossible, isn’t it? If we’re honest…

[laughs] It’s basically impossible…

It’s just this side of impossible, which is why we still do it…

Right.

So I think that might be the choice if the Changelog audience are kind of like quite serious about their work.

Right.

What do you think, Natalie?

I would say developer.

Okay. Good guesses, because those two tied for first place? 42% each.

Yeah, interesting.

And this was a pretty good sample size. We had a few hundred people reply, so it wasn’t like a GoTimeFM poll, where we get 23 votes. Come on people, follow GoTimeFM and vote on our unpop polls. We need you, we need your help. The Go community depends on YOUR votes.

[01:06:00.28] Yeah. And how am I going to get hair transplant if we don’t get more listeners on Go Time? So come on, everyone, listen in. Listen harder! Go and listen to the ads twice.

Yeah.

Go listen to the ads twice!

And answer the poll.

And answer the poll, yeah. Okay, so 13% of respondents were happy to be called a programmer. 3% of respondents want to be called coder.

Really?! Coder… No one wants it.

Yeah. In Leslie Lamport’s video that we’re referring to, he defines coding and programming as two different things. And this was something that people said to me was that coding is like typing. And developing or programming is much more than just typing.

So my unpopular opinion - this is a huge setup; we’re going to cut this part out of the video. My unpopular opinion is that it’s inappropriate to compare coding to typing. So if you’re a writer, and you do all the things that writers do, think of the story, the characters, your ideas, design the story, etc. and then you go to write - those are two processes. That’s fair with me.

If you’re a developer, and you go doing all the things that a developer is going to do - plan, make decisions, test things, estimate some points wrongly, whatever you’re gonna do, and then you go to write the software, I think it’s inappropriate to say that the coding part of a developer’s job is akin to the typing part of a writer’s job. Because typing and coding are different. It’s the writing part. So a writer writes, okay? Typing is just a thing that goes mechanically between you and a machine. But a coder codes; a developer codes. And so there’s more – coding is much more than just typing. I think it belittles it to compare it to typing.

Yes, I know exactly what you mean. When I first read that, I thought they were saying that coding is really just the act of getting it into the editor. And the programming is happening outside of that, and it’s the bigger thing. But you’re right, definitely between typing and coding – I mean, you have to type in order to get coding to happen as well. So I think yeah, that is interesting that they these - but I’m surprised coder just got 3%.

Nobody wants to be a coder.

Honestly, I thought that sounded the coolest. But I might be out of – have I reached the age now where I don’t know what’s cool?

It might be an age thing, because I think programmer is an older term, that I think probably people who’ve been around longer – I mean, it used to be programmers write programs. But then programs became apps, and programmers kind of became developers. I don’t know why or when, but it seemed like that kind of happened, and programmer has fallen a little bit out of trend.

Yeah.

Out of vogue. But coder is like - nobody wants to be that.

I think to me, when I hear code, I’m thinking of code monkey. I heard this term so many times in the negative context of somebody saying “I want to do more than being a code monkey.” I think this could be a reason.

That’s a good point. Maybe that’s why people associate it with that, that concept of “Just take a ticket and do the coding, you code monkey.” And like, we don’t want to be put in that box. That might be true.

That could be it. I understand that. But in a way, I quite like being modest. But then I’m in a position where I can’t be. Obviously, not everyone can just be immediately modest. But you have to sell yourself when you get into your career, and stuff. But I like it when you see people that have invented core concepts that we all use in their bio just as programmer. It’s very understated, and I think that is quite cool. So it may come back, it may be retro, hopefully.

Right. We’ll see.

But I quite like developer, because it sounds it’s developing; it’s never finished. An engineer - you’re almost like at some it’ll be engineered, and then it’s done, and it’s delivered. Whereas there’s something nice about the fact you’re telling people “This isn’t going to be finished. So get that out of your head now! This thing is going to drag on!”

[laughs] Well, when I think of engineering, I think of like building a bridge, which is very much rooted in years and years of physics, and math, and…

Metal…

[01:10:23.01] …known equations. And we can engineer a bridge, and then it’s done.

Tarmac…

We know exactly what it’s capable of, and what it will buckle under. And I don’t feel like software is ever that. We’re learning constantly. It’s more like that whole flying a plane, or changing it while it’s flying, or something.

No, it’s true. It’s because the speed at which we can iterate, and that feedback loop actually, which is one of the points that’s come up a few times throughout this. Having a feedback loop, and having a short feedback loop. That is what enables to move quickly, because you can try things, walk back if you got it wrong, you haven’t committed loads of resources to it, because it was just a small thing anyway, so you don’t feel bad… And you can then correct course… I think that, working at that kind of resolution is the way to do it. And that’s why it’s so hard to estimate stuff when none of us are doing anything we’ve really done before. We’re probably doing something no one’s ever done before, in lots of ways, and so we should give ourselves a break… And tell our managers to shut up!

[laughs]

Perfect way to finish this episode about velocity. Gentlemen, thank you for joining. That was fun. I don’t know if you can hear in the outside it’s the firework of Berlin celebrating the sunset of the longest day of the year.

Oh, wow.

It’s done. The day is done.

Oh, congrats, Berlin.

It happened. It’s been a pleasure spending it with you.

Oh, well, a long day, but…

We talked to you all day.

It felt like it…

Throughout the sunset.

It’s been a pleasure. There’s not two people I wouldn’t rather spend an entire long day with… So thank you very much. It’s okay just to say that, but… Fine…