Software estimates have never worked and never will | Hacker News Reader

Software estimates have never worked and never will

world.hey.com

11 pointsaard11 comments

One of my favorite tech Twitter quotes:

> time estimates from software devs actually make sense if you think of them as "this is how long it would take me the second time if i did this twice in a row"

There is a lot of confirmation bias in the industry around estimates. If an estimate is ever wrong, it's never taken as evidence that estimation in general is a flawed practice. The failure is always attributed elsewhere, usually to a lack of effort or focus. But if an estimate happens to prove true (even broken clocks are correct twice a day), everyone pats themselves on the back and says, "look how predictable we are. We are so good at estimation."

Nope. It does work. Most of the time if the developers are qualified they are able to give decent estimate for how long assuming the task is clear enough.

That's exactly where you are in disagreement: whether a "task is clear enough"?

If it's tiny and well described, and you've got a developer who has already built something very similar in the past, you'll likely be able to estimate correctly.

If it's medium sized or large, but well described, there's likely an off the shelf product you could get.

But just changing a couple of "tiny" constraints like use a different IaC framework, database or language, makes a known problem "novel" in a way that makes it unpredictable.

So let me put the question on its head: describe me a medium-sized or big project that you correctly estimated ahead of time without resorting to re-scoping the work? Anything that's at least a couple months for a team of 5-6 people.

In my somewhat limited experience the key word here is "novel" and it's where I too disagree with your parent poster: One is most often asked to write a software because of some task that has not yet been solved, meaning one has to inevitably make an invention, which are, like future herself, inherently unpredictable.

>"One is most often asked to write a software because of some task that has not yet been solved"

From my experience as a contractor who creates new products for clients it is still very predictable. I am not being asked to invent new interstellar engine. Being novel at what product does does not mean that development itself includes novel software concepts. I have decades of experience developing "new" products, am very good at it and I predict and deliver on time.

It seems you never had to work with that specific kind of people who write the tasks (no matter the size), but :

1°) don't know exactly what they want themselves, so the task is missing key points you discover while coding the task,

or 2°) are writing tasks for someone else and the communication is not good so some info is not clear or missing,

or 3°) the task is written too soon ("just in case") and needs external information to be complete,

or 4°) change their mind while you already begun to code

I develop new products for new clients for living. Nothing I do usually repeats previous work beside some generic patterns. It is my specialty and this is why clients like to work with me.

>"describe me a medium-sized or big project that you correctly estimated ahead of time without resorting to re-scoping the work? Anything that's at least a couple months for a team of 5-6 people."

Easy. One example would be integrating bunch of telecoms following local market deregulation in Canada's CLEC's heydays. I and my buddy were leading a team of about 10 people (changing on on need basis but all senior developers) and first delivery signed off by client did happen in 6 month which was my initial estimate. The estimate itself had taken about a month to prepare before given to client. I develop new products for new clients for living. Nothing I do usually repeats previous work beside some generic patterns. It is my specialty and this is why clients like to work with me.

To me it sounds like you did do some rescoping of work: if the number of engineers was fluctuating, that's the buffer you used because you might have misestimated.

Also, did your "first delivery" include exactly everything that was part of that initial estimate?

I would imagine your clients figured something else is higher priority and that pushed out some of the initial plan: if so, that would also be rescoping work.

Again, I don't think meeting deadlines is impossible, but that you get there by reprioritizing and rescoping work as you go along. And sure, resizing the team too.

On top of that, even if you really did deliver everything you signed up for 6 months ago (and not more — we don't want to be overestimating/underpromising) without fluctuating capacity or scope, most in-house teams do not get 1/6th of the time to estimate something before they start on it (effort sizing is mostly useful to decide on what to do, and then that time is best spent building it). And perhaps they couldn't do it even if they did get the time.

Nope, it doesn't work on anything that's not trivial or done before. And if the task is clear enough, that means they have already done a similar task and also somebody went and clarified it, which is time that somebody could have used to actually implement it.

From my perspective, there are only three useful estimates:

1. This will take very little time, and everything is clear, eg a label change

2. This will take some time, but we do know how to do it: eg some new microservice doing similar things to other existing microservices we are familiar with or a feature similar to features we have built in the past.

3. We don't know how much this will take as we haven't done similar things before.

That are the only useful estimates, and if anyone wants more detailed ones, well, tough luck, I am not wasting mine and my team's time.

Reply on news.ycombinator.com