3 ms·

> "How long will X take?" > > "I don't know, I've never done X before." I fail to see how your example makes any case on how estimating how many resources a pr

> "How long will X take?" > > "I don't know, I've never done X before." I fail to see how your example makes any case on how estimating how many resources a project needs is stupid. At most your example argues that asking inexperienced and clueless devs to estimate stuff they know nothing about produces highly unreliable information. The main difference between hacking away at a code base and software engineering is identical to the difference between construction workers and civil engineering. Sure, estimating is hard. Yet of you want reliable estimates you need to check with experienced professionals.

ALittleLight 7y ago
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.
- commandlinefan 7y ago
  > 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?”
  - hinkley 7y ago
    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.
outworlder 7y ago
> 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.

ALittleLight 7y ago

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.

commandlinefan 7y ago
> 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?”
- hinkley 7y ago
  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.

outworlder 7y ago

> 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.