"A week" is a terrible estimate for complex things that have components that you can't foresee. If you lose "a day" on some problem outside of your control (compiling starts to fail and it turns out someone checked in some code into your branch by mistake), you've basically wasted 20% of your estimate.

Never say a week when there's the chance something will require a month because you didn't understand it.

You need to learn this lesson. A week is a blink of an eye in software, and only things you understand take a week.

"Really? X will take 'a month at least'? Why?"

"I don't know why, but I don't feel comfortable guessing less because I don't fully understand X."

"Okay, that's not a good way to estimate. Why don't you spend some time to come up with a plan for X and we can estimate it after that. When can I have the plan?"

You can have the plan in a week.

Yes. This happens at my shop all the time and it's absolutely terrible. Each sprint starts out positive and ends with panic attacks.

I've solved this by not panicking about software someone else owns. Worked out OK so far. They can fix their processes and expectations (I'll help!) to get more value out of me, or choose not to. Not my problem. Environment gets too toxic, well, see ya, and good luck (you'll need it).

This would've worked if you'd taken your initial estimate (1 week) - bumped it to the next unit (1 month) - then doubled it (2 months). Maybe you would've been given 9 or 10 weeks, so you'd have the week for X, and 1 month each for Y and Z.

I understand this is a contrived example, but it's strange that, when you take a real project that "overran" based on the initial estimate(s), and you apply the formula - just how often the formula is actually really close to the actual amount of time.

Not always - but more often than not.

I've worked about 10 years at FAANG companies and I'm yet to meet the experienced and expert devs who are good at estimating things. I think your characterization of "inexperienced and clueless" devs is off.

The reason I think my example illustrates a problem is it's moving away from agile. I shouldn't estimate X without understanding it? Okay, I'll take the time to figure out, look around corners, etc. I realize I need Y and Z. I've got to estimate those, to estimate X, so I start working with other teams to figure these things out, and drawing up plans and schedules and who's doing what when to get all this stuff delivered. Now we're basically at the waterfall model where we're planning everything out before doing it.

The other problem is that all the process is genuinely a waste. If we need X then let me work on it rather than do all the planning and scheduling nonsense. The schedule will be wrong anyway. If I have problems, need help, etc with X then I can raise those concerns and management can react in an agile way.

> If we need X then let me work on it

If you look through the managers who are weighing in on this thread, you’ll notice a common perspective: they don’t trust you to actually work on something. That’s why I have so little hope for any software methodology - even if it starts from something positive (like XP, which was the precursor to “agile”, did), it will be turned into “I know all of my programmers are stealing from me, how can I stop them?”

In part because we still measure effort in hours instead of in wear and tear. That guy answering comments on Hacker News is probably trying to recharge, not steal from you.

I learned recently that the crane operators that unload cargo ships at some major ports can’t work more than four hours at a time. The movements are too precise and take a great deal of attention. I think you can work two shifts per day but there’s a mandated gap of some number of hours between them.

> At most your example argues that asking inexperienced and clueless devs to estimate stuff they know nothing about produces highly unreliable information.

Wow, so much hubris in such as small post.

Unless you have been doing the exact same thing forever(in which case you are at a risk of being replaced), new work _always_ comes with a degree of uncertainty. Be it new technologies, new business requirements or what have you. I have never worked in two identical projects in my life.

The correct answer would be a 'spike' or proof of concept. Either that, or hire those magical developers you seem to have who know everything there is to know.