Live data from Hacker News

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

medium.com

121–130 of 420 posts

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

#121

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…

Flip it around: it's really hard to budget, plan for staffing, make commitments, etc. without the ability to give estimates of this sort. The best thing to give yourself when giving estimates of a dificult sort is the freedom to be wrong, and the ability to express how confident you are in such an estimate.

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

#122

Earlier quoted context omitted.

That's one of the big reasons that I've become a proponent of Donald G. Reinertsen's approach to product development. He emphasizes a variation of the cost benefit formula + urgency, called Cost of Delay for prioritizing that basically boils down to "Value / Time Remaining" because your cost is the time remaining. It naturally prioritizes work based on shortest time to value because, unless the value proposition is e…

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

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

#123
post #45

I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes…

> One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery.

This is a brilliant summary, thank you.

The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and the users are on-hand throughout the process for feedback and reevaluation.

The worst experiences have been waterfall contracts, developed by an internal simulation of agile. The software team does frequent "releases" to business or management, who provide feedback and feature requests, but the actual recipients are uninvolved outside of occasional demos, or contacted only indirectly by non-programmers. The result is almost always thrashing, with time and effort spent pointlessly satisfying the forms of agile even though the real timeline and customer feedback are unyielding.

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

#124

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 done in a specific set of technologies that haven't changed.

For me, I simply make a very conservative guess and use a 2x or 2.5x multiplier to be safe. I'm usually far ahead of schedule but there have been occasions I as happy I added a 2.5x multiplier in. Everyone is typically happy... the fact is, my estimates are garbage.

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

#125
post #15

Earlier quoted context omitted.

Your argument here is against "business". In a dream world, where we could build for building's sake, and create "more perfect" things with no considerations for cost, I'd agree with you, but businesses (in the abstract) are a math function: Does it cost us less to make this than we charge for it? If so, we are a profitable business, if not, we are an unprofitable business. Managers are there to manage costs, to prot…

Casinos are quite profitable, yet they have no idea if the next card being drawn will be profitable or cost them thousands of dollars.

I'm sure they have very good idea. Statistics, game processes design, everything is engineered towards stable and predictable profits.

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

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

"Scoping" however is still needed.

If you ask me "How long will it take to add a button to this page", that's a very ambiguous question.

I can solve the problem in a few ways: - Tack on a plain html button element - Add a button from an existing styleguide/library/design system. - Build our own button component instead of reusing one. - Build a full blown button editor that allows a non-software engineer to use a WYSIWYG editor that will create their own custom button and insert it on the page without code.

Now obviously there's a range between these, going from a few seconds (plus deploy), to months or years of work.

The project/product/whatever managers and the tech leads/engineers need to work together to agree on scope. An arbitrary deadline can be picked and then engineers have to do whatever they can up to that deadline. Or we can agree on minimum functionalities with onbound deadline that MUST be created regardless of how long it will take. Realistically, successful projects will be a mix of both, along with various forms of padding and revisiting estimates along the way to account for unknown and mistakes.

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

#127

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 think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start. (I mean, reasonable dependencies. No one can account for unknown unknowns, but the software engineering field is not an art, more of a skill, we do have well established processes to minimize the surprises). Is this something that HN audience is interested in?

> I think there is a way to give an estimate (have been doing it myself for a decade), even for dependencies that are not known from the start.

I agree with this. The problem is that estimates vary, and that management teams often don't understand the way they vary. It's one thing if your estimates are precise and are generally accurate within 20%; it's another if your estimate is "it will likely take between six months and three years", and a third of the time the actual required time falls outside even that range.

... and yes, there are many projects for which such a large estimate wouldn't be unreasonable; nor would it be unreasonable for there to be unexpected breakthrough or challenges that significantly impact the timeline.

> Is this something that HN audience is interested in?

I can't speak for the community, but I think the only way you can know the answer to this question is to post it :)

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

#128

Earlier quoted context omitted.

That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.

> multiply by the LarryDarrell Constant of 1.5. Funny thing. If you do this organizationally, then you eventually end up making larger and larger estimates. IMO it is better for management to understand the inherent risks associated with engineering estimation and build the padding on their end.

And the time estimated is always used up, at a minimum.

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

#129
post #15

Earlier quoted context omitted.

Your argument here is against "business". In a dream world, where we could build for building's sake, and create "more perfect" things with no considerations for cost, I'd agree with you, but businesses (in the abstract) are a math function: Does it cost us less to make this than we charge for it? If so, we are a profitable business, if not, we are an unprofitable business. Managers are there to manage costs, to prot…

Casinos are quite profitable, yet they have no idea if the next card being drawn will be profitable or cost them thousands of dollars.

But they know that the sum of all cards drawn will be profitable, because their practices guarantee it. Normal businesses cannot guarantee that the sum of all their projects will be profitable.

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

#130

Earlier quoted context omitted.

That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.

> multiply by the LarryDarrell Constant of 1.5. Funny thing. If you do this organizationally, then you eventually end up making larger and larger estimates. IMO it is better for management to understand the inherent risks associated with engineering estimation and build the padding on their end.

Hofstadter’s law: It always takes longer than you expect, even if you take into account Hofstadter’s law.
Post reply on HN