Live data from Hacker News

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

medium.com

151–160 of 420 posts

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

#151
post #126

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…

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

> because of the complete lack of pressure

I would say it may be due to more of a lack of focus.

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

#152
post #103

Earlier quoted context omitted.

I'd love to hear what you have to say in the topic.

Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI element…

This is roughly how I was taught to estimate. It is accurate but takes time and everybody hates the result. Management halved my estimates without telling me, made fun of my mentor’s estimates, complained about needing to know everything upfront (not very agile eh!), etc. I think you are right and estimating is more of a solved problem than we think, some people just don’t want to admit it!

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

#153
post #126

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…

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

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 don't understand there is not much you can do but probably look for a better gig.

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

#154
post #62
post #53

Earlier quoted context omitted.

I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?

Nothing per se, is just going to make both your life harder and make it very difficult to produce software that is useful for others. You need to talk to people to be able to produce the software they need, ultimately.

Yeah like TCP/IP or Bitcoin.

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

#155

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…

There's a balance to it for sure. It sounds like estimation was taken far too seriously on your team if it was affecting you outside of work too. However, estimation is one of the primary skills of a software engineer. It's always hard to estimate well, but it's infinitely harder for a less technical person to do it for you. I think it's important to understand that and do one's best to improve at it over time.

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

#156

Earlier quoted context omitted.

Sorry, tried to answer and apparently I was "posting too fast". One may start with enumerating the features that needs development (a.k.a. "user stories"). Also enumerate external dependencies, team overhead (more people working together means overhead is greater). For each feature enumerated in step 1, try listing as much detail as possible, also listing open issues and unknowns. For example, list all the UI element…

This is roughly how I was taught to estimate. It is accurate but takes time and everybody hates the result. Management halved my estimates without telling me, made fun of my mentor’s estimates, complained about needing to know everything upfront (not very agile eh!), etc. I think you are right and estimating is more of a solved problem than we think, some people just don’t want to admit it!

Oh yes, my experience as well. I just hope these companies do not manufacture aircraft or nuclear power plant software.

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

#157

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…

>That's when I knew it was time to leave that team

Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more stories with additional time.

I mean, it happens in engineering sometimes. We engineer our way out of it, and the engineering is solid in the end. But no, we blew up our story, so all that working nights and weekends to get back on track are for naught.

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

#158
post #112

Agile was dead to me when I finished my PhD and joined a company that paid a Scrum consultant more than they paid me to help us move tickets without knowing what was the project about.

You'll probably find that the most highly paid people in most organisations only have a fairly abstract understanding of the work being done. This is nothing to do with agile.

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

#159

Earlier quoted context omitted.

> including tech debt Tech Debt is not little, or we wouldn't carry it around, rather than devote time (and risk of revealing new unknowns) to fixing it. My agile experience has always favored conquering little stuff first, since ppl recognize stories more than points (which vary in value, over time). This, unfortunately, sometimes leads to the hilariously subversive act of splitting a story up into as many tiny piec…

splitting a story up into as many tiny pieces as possible Honestly I think that's the intended outcome from the business's perspective. The smaller the piece of work, the easier it is to assign a cost and a benefit to it, and the easier it is to hand off to another developer.

>... and the easier it is to hand off to another developer.

I have never seen this work out in practice. And it's like a 1%-of-the-time thing anyway.

On the flipside, I've seen quite a few hours wasted adding fake subdivisions to tasks, probably close to 30% of the time. Outside of small, known bug fixes or tech debt cleanup, it's rare for a thing to wholly fit within a sprint.

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

#160

Earlier quoted context omitted.

an area where every interaction is a performance Feel ya. Surprisingly enough, I'd say that I've not had to attend so many boring meetings in my career but certainly I'm just lucky. Also, once I did get a manager who was an "agile guru" and he was annoying. He talked to me like he's the jedi of software development and I'm his padawan. Thankfully, he got fired.

I had a professor at university who acted that way about Agile. He thought he was literally Uncle Bob incarnate. But when you looked at his credentials, he had never once worked in a real production environment, he had only ever taught.

Teach, those who cannot do, do.

-- Yoda

Post reply on HN