Thread by @matryer

I agree with @ScribblingOn

It's time to get rid of estimates in software engineering. They don't work, do more harm than good, and drive people to act in dishonest ways.

Buckle up people, it's a thread.

"How long is this going to take?" feels like a completely reasonable question, but how come "I don't know" isn't a
reasonable answer?

"We just need a ballpark figure, you won't be held to it," they lie.

Well how come we just had to work the weekend?

Estimates are an effort to try and predict _when_ something is going to be ready. This is necessary so the rest of the business (sales, other dev teams, cult leaders, etc.) can line up and coordinate their efforts.

The reason for estimates is entirely respectable.

The trouble is, we don't know how long something is going to take. We just don't know. It's a hard truth, but truth nonetheless.

In rare cases, work is repetitive enough to allow for accurate estimates - but most of software engineering is all about building something NEW.

The worst time to make decisions about how long something is going to take is at the beginning (or before) we've started, when we have the least amount of information.

Even after just a day of working on it, we're infinitely more qualified to guess. But it's still guessing.

So people started to build in a 'buffer'.

Some say, "have a guess and add a week" or even "double it".

I've ever heard of someone who multiplied the estimate by 4 before sharing them.

Does it sound like something is broken to anyone else?

The real trouble starts when we inevitably miss the targets.

All of a sudden, we're LATE. The team is BEHIND. We're FAILING. We're AMBER or even in the RED.

All of this avoidable negativity and blame is completely manufactured out of these "ballpark" estimates.

The self-esteem of team members and its impact on productivity is dismissed by some as irrelevant, "an emotional thing", or not professional.

Some people think it's some kind of weakness, rather than a simple undeniable objective reality.

A happy team is just more productive.

Telling a team that they're BEHIND does not magically make them work harder, it has a much darker, often hidden effect.

"Cut corners, add tech debt, skip tests, hack it in for now, just do whatever's easiest."

When you start to ignore the QUALITY, it's the beginning of the end.

Once there is one awful hack in the code, it's very easy to excuse another, and another, and so on.

The quality of our work needs to be non-negotiable.

medium.com/@matryer/broke…

So far I'm just complaining, so let me propose a solution that has worked, and continues to work for me.

I learned it when I was first studying Agile methodologies, and given it's such an old buzzword, is suspiciously missing from a lot of team's processes.

1. Pick a hard deadline for the work

Never mind estimating to guess when something is going to be finished. Fix the finish date.

This gives all interested parties something they can align with. They can even tell customers about it, depending on how brave* they are.

2. Fix the quality

No more cutting corners, or hacking things in. Only perform at the highest possible quality. No rushing. Test coverage should be perfect, all documentation correct and up to date, code a shining example of our best work.

3. Let the scope be the variable

Do less.

Commit to the deadline, but don't fix the tasks that need to be done in that time.

Focus on solving the problem, but allow the definition of that solution evolve.

medium.com/@matryer/halft…

This approach forces you to prioritise the important stuff.

You can't have everything, so what do you REALLY need by the deadline?

This is a very valuable exercise in understanding the real problem faced by users. It's a feature, not a bug.

Then trust the team to do their best, and to achieve as much as they can.

Devs are never happier than when they're delivering real value to the business, and solving real people's problems.

If you don't trust your team to do this, you have much bigger problems that will not be solved by holding your team to estimates that we're only supposed to be "ballpark" in the first place.

Pace.dev is a minimalist project management and team comms tool that admits these realities and others, and helps foster more positive working practices for teams.

So if you like this way of thinking, why not give it a go with your team for a couple of weeks?

(It won’t surprise you to learn that Pace doesn’t have estimations—we didn’t want to encourage teams to lie).