</p>
As a developer with close to twenty years of experience, I've been asked to estimate work time and again. The primary method for estimation has been using Agile methodologies, which most in the tech industry understand all too well. You pick a t-shirt size, Fibonacci score, etc., to essentially say, "This task is going to take an hour, a day, a week, or a few months." As I was writing about this subject on an email chain recently, I wanted to expand on it here. Namely, to answer the question: Is estimation bullshit?
It's easy to dismiss estimates outright. They are for project managers who, at the end of the day, are supposed to be protecting the team. The team needs to have some skin in the game, namely, some expert opinion on how long a task is going to take. So that the timeline can be communicated up the chain of command.
While this might seem very "work 1.0," where you'd have a factory line, and this newer work is more knowledge-based, it doesn't really matter. At the end of the day, a project manager needs to be able to let organizations know how long an effort is going to take. But since this is my blog and I love diverting to Socratic self-dialogue, let's dive in.
Why? Why does it matter how long a thing takes?
Well, I'd say, it matters because someone is paying a premium for that 'thing' to be created.
Exactly, so that 'thing' needs to be tied to either a revenue-generating feature or a quality-of-life improvement.
So is that saying anything that doesn't give value back to the user is not worthwhile?
I think that depends on whether a feature creates novelty to attract attention.
So attention or revenue?
Sure, estimates are required because anything of value takes time. People need to eat, and an organization needs money to provide itself the time to grow.
So it's an ouroboros.
Yes.
Since Cory Doctorow won the word of the year award for 'enshitification' from this article, I'd say that anything that gives value to the end user, as a developer or PM, should be aiming for. This relates to estimates as well, you should be aiming to do the most good for the most people on your platform, which means having a gist of an idea for how long something is going to take. Then implementing.
So, are estimates bullshit? Let's try and break it down pro and con.
So again, this is mostly self-socratic thoughts, but I keep thinking about non-knowledge worker jobs. For example, you can get a new bathroom installed and have a contractor come over and estimate the amount of effort that it's going to take. Assuming they have done similar work, it's going to be around the same idea.
People use contractors all the time, so using them in sprints shouldn't feel like bullshit. Since you are also working with diverse teams, it's not so much installing a new bathroom but installing a whole Willy Wonka factory sometimes. So you need to know when what features are going to drop.
However, are they bullshit? I still think so, but it's the same as deadlines. Things can happen, but that doesn't mean you shouldn't strive to meet them. They give you a north star or something to shoot for, and at the end of the day, in software engineering, isn't that a good thing?
---
updated: 16 December 2024.