Hacker News Reader

Comment by lr4444lr | Hacker News Reader

I think a lot of people commenting are not giving a charitable interpretation to the question. Now why any estimate is needed, but why should the dev be expected to have the right prognostication? As a dev, I have to admit it's a fantastic question. The reason estimates go awry almost always come down to things outside my control. Why am I expected to make predictions based on that? The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate. And if I agree to it and fail to meet it, the judgment should go above both of our heads: was I delinquent, or was I blocked because someone else didn't do due diligence?

View on HN

I’m in precisely this situation right now. I’m an external consultant being asked by a dev team lead how long it’ll take for his team to deliver a project. He’s the one approving holidays, he’s the one allocating priorities. He’s the one that knows the skill levels of his staff.

I’ve been in the exact same situation a year ago, where another manager got mad at me for a delay. It was caused by him approving his entire team to simultaneously go on 3-month holidays when the COVID travel ban ended. Apparently that was my fault for not estimating accurately.

The people getting paid salaries to have a bird's eye view and veto power over those kinds of changes that could screw with my deliverable should be the ones knowledgeable and accountable for that estimate

But they are accountable to their stakeholders (clients, upper management, etc). They take your estimate and many others from other people in the team and work those into a delivery plan.

A good manager will know how to manage risks and remove blockers in a way that gives a developer the best chance to work within the estimate. A bad manager will usually have no plan and put all the blame on the developers if things go awry.

Agile frameworks often remove the developer as much as possible from the time estimation effort, instead relying on past performance, and attempting instead to have the developer focus on breaking work up evenly.

Sure, this helps by removing some of the bias, if done right. But many times devs end up perverting the original intent of the framework.

Eg: I've seen many scrum teams transforming story ponts into days or vice versa missing the actual purpose.

If you abdicate any responsibility to estimate the work how can you agree to any estimate?

I am responsible for telling the person promising how long the work would take as scoped out, given the competing or potential problems which that person is also responsible of informing me exist. It's not that I provide no info - it's that I can't be authoritative about delivery times in an ecosystem I don't entirely control.

I think this argument is not about engineer vs manager. It’s about junior vs senior engineer. As you gain seniority and tech-lead others you take on this responsibility. I agree that junior engineers shouldn’t do estimation, but rather senior engineers should set the expectations.

A key component of the due diligence you're expecting involves asking developers how long things will take. Savitha is building a new feature with about 2 more weeks to go, but it can't be deployed until a guy Jim on some other team deploys suchandsuch dependency upgrade. Should I commit us to a mid-April release date, or will Jim need more time? I don't know, I'd better go ask him.

Of course. What I'm saying is, I see failures IME as Jim putting something into the code base that makes Savitha's work consequently incompatible, which was not surfaced to her as even a possibility when she was asked to give her initial estimate.

Reply on news.ycombinator.com