Dear Agile, I’m Tired of Pretending (2018) • Hacker News Board

Re: Dear Agile, I’m Tired of Pretending (2018)

#191

Post by vnorilo » Mon, Jul 01, 2019, 6:49 PM UTC

Frost1x wrote: post #124

bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

I'm the same way but only about 15 years experience. I have a friend recently retired who has done a wide variety of software development since the era of punch cards (at least 40 years development) and he agrees with me entirely. I'm not sure how people can provide any reasonable estimates, especially these days when technology is shifting even faster under your feet unless it's a clone of something you've already d…

This is what I do! I disagree on 'garbage', though, I would say that you sound like you estimate very well, and that factor of 2.5 uncertainty is reasonable given all the unknowns in this line of work.

Re: Dear Agile, I’m Tired of Pretending (2018)

#192

Post by BurningFrog » Mon, Jul 01, 2019, 6:49 PM UTC

kryogen1c wrote: post #184

avgDev wrote: post #153

Earlier quoted context omitted.

I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…

One way software is different is that you're always doing things you've never done before. Because if you've done it before, you can just reuse that code.

This is probably not how the refueling nuclear aircraft carriers projects work.

That said, it's usually not quite as completely unknowable as your last sentence. Then again, it frequently is.

The real tension is about trust. When people think engineers are lying about their estimates.

Re: Dear Agile, I’m Tired of Pretending (2018)

#193

Post by danmaz74 » Mon, Jul 01, 2019, 6:49 PM UTC

Frost1x wrote: post #124

bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

I'm the same way but only about 15 years experience. I have a friend recently retired who has done a wide variety of software development since the era of punch cards (at least 40 years development) and he agrees with me entirely. I'm not sure how people can provide any reasonable estimates, especially these days when technology is shifting even faster under your feet unless it's a clone of something you've already d…

Even those estimates are good for people who have no clue if something can take 2 weeks or 6 months. They're not garbage.

Re: Dear Agile, I’m Tired of Pretending (2018)

#194

Post by SkyBelow » Mon, Jul 01, 2019, 6:50 PM UTC

>Quit with the local optimizations already, and realize trust is the №1 issue.

So how do you trust someone who would outsource your position if they believed it would save money and reduce their work load? Management and employees have an inherently adversarial relationship that is poisonous to trust. I think it can still develop at times, but under our current culture where everyone knows someone whose job was made redundant with little recourse for their employment, you might as well be asking for a coconut to grow in an active lava flow.

Re: Dear Agile, I’m Tired of Pretending (2018)

#195

Post by ALittleLight » Mon, Jul 01, 2019, 6:51 PM UTC

geezerjay wrote: post #163

ALittleLight wrote: post #96

Earlier quoted context omitted.

"How long will X take?" "I don't know, I've never done X before." "Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for scheduling. Not written in stone, ha ha." "Uh, a week?" "Okay, great, so if I say 8 days you should have it done by then?" "Yeah, I hope so." "Great, thanks." Day 3: actually doing X requires unforeseen Y and Z which will each take a month. "We need to add Y and Z to the schedul…

> "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…

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.

Re: Dear Agile, I’m Tired of Pretending (2018)

#196

Post by rhizome » Mon, Jul 01, 2019, 6:54 PM UTC

kryogen1c wrote: post #184

avgDev wrote: post #153

Earlier quoted context omitted.

I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…

What you are describing are reasons why software engineering isn't Engineering.

Re: Dear Agile, I’m Tired of Pretending (2018)

#197

Post by jtolmar » Mon, Jul 01, 2019, 7:00 PM UTC

bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

Most time estimates aren't necessary in the first place and it's aggravating that we need so many of them. Yes it's mostly a stick to beat devs with.

But since folks reading this will probably need to make estimates anyway, this tends to be accurate: Estimate it'll take as long as the most recent similar thing you've done (real time, not heads down time). Resist the urge to trim out parts of the previous task that aren't related (you'll have new yak shaving) or related to mistakes you've learned not to make (you'll make new ones). If it's really different from anything previous, look for a time you had to learn something and implement a new system based on what you learned (you're allowed to be meta).

Re: Dear Agile, I’m Tired of Pretending (2018)

#198

Post by [deleted] » Mon, Jul 01, 2019, 7:02 PM UTC

RocketSyntax wrote: post #182

shados wrote: post #126

Earlier quoted context omitted.

> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…

It's more about what is BEHIND the button.

[deleted]

Re: Dear Agile, I’m Tired of Pretending (2018)

#199

Post by xwdv » Mon, Jul 01, 2019, 7:02 PM UTC

bougiefever wrote: post #88

I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…

No.

Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates.

You must never turn estimates into a promise, always remind people they are estimates.

Want to give fast estimates? Here’s how:

1) first determine the scale of the task? Is it a year, month, week or day kind of task?

2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it.

I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won’t take more than a day.

Re: Dear Agile, I’m Tired of Pretending (2018)

#200

Post by commandlinefan » Mon, Jul 01, 2019, 7:04 PM UTC

ALittleLight wrote: post #195

geezerjay wrote: post #163

Earlier quoted context omitted.

> "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…

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 n…

> 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?”