Comment by a_square_peg | Hacker News Reader

Comment by a_square_peg | Hacker News Reader

Parent Full thread

I see posts like this and wonder if software developers are in such high demand that they're able to call the shots these days but many of these points are come off as very arrogant.

> Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature.

While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some accounting and have them do a legal brief?

> Stop estimating.

How does this person think an organization schedule, budget and allocate resources?

> In my opinion, Have a minimum team size of six.

To build what? Some production software can be built by one person. Some need hundreds. This is like saying an organization needs a minimum of $1.5m annual budget for software development because it's software development.

>> Stop estimating.

> How does this person think an organization schedule, budget and allocate resources?

Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously anyway.

That's just a way of estimating that is likely quite accurate in a completely steady state.

But what if you know you're changing things significantly, and that's the whole point you need to think about resources and schedules? Like starting a new project?

Use data on how long it takes to complete “projects.” Or break the project down into your best projection of the component tasks and multiply “number of equivalently sized tasks” by “average time to complete that sort of task over the past X months.”

Regardless, “collect and use data from the past,” does not require a “completely steady state,” and is pretty easy to modify. I’d feel a lot better having a conversation around, “this is totally new, do we think it will take about 2x or 5x longer than our normal projects?” Vs “this is totally new, so everyone guess how many months it will take without looking at any relevant data on either past project duration OR the accuracy of your past guesses.”

When people talk about “estimating task size” they almost invariably mean some planning-poker version of the second. Especially in TFA where they bring up forecasting as a better alternative.

Reply on news.ycombinator.com