Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"No, it's less effort than that"

smartguess.is

Post reply on HN
Print view View original

11–20 of 388 posts

Re: "No, it's less effort than that"

#11

Post by ejb999 »

zeroCalories wrote: post #5

Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.

>>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret.

...and nobody gets faulted by management, because they completed the story in the time they committed to.

On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.

Re: "No, it's less effort than that"

#13

Post by pydry »

If you're asking for estimates from devs at all you're probably pushing waterfall on them.

If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.

Re: "No, it's less effort than that"

#14

Post by Scarblac »

anonzzzies wrote: post #9
Scarblac wrote: post #6

It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between. Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary. If you are asked to change your estimate, see it as an invitation to…

Often clients don't understand what they want; like you say, the difference between met plonking in a basic combobox/select vs some much nicer, and much more fitting the case, custom ui element doesn't really translate to anything many people outside IT understand. To explain this difference it can be drawn, but stakeholders still don't understand what's going on as they don't see & feel it, so you have to make it wo…

The other extreme is that management was talking about new functionality and we kept seeing it as just another small feature in our existing product, and kept giving them estimates of a few weeks. Until they ended up setting up a whole new team for it because what they had in mind was a completely new product fully focused on that functionality.

It's all communication, programmers and stakeholders live in different worlds.

Re: "No, it's less effort than that"

#15

Post by albert_e »

m0llusk wrote: post #12

This is a bad metaphor. You can't make the sun come out faster by dropping features.

yeah i cannot use this analogy to tell my client to backoff.

they will say: if you guys are only watching the weather and telling me whether it will rain or not -- I dont need you guys then. I will hire someone else - who will build me a working umbrella within my budget before it starts to rain.

or some other imperfect analogy that we cannot question having done the same thing ourselves first

Re: "No, it's less effort than that"

#16

Post by atoav »

IanCal wrote: post #7

A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders. I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day. > There is back-an…

I get that. But as a tech guy I sometimes get itchy when the actual reality of things is ignored. A good example would be when a customer demands something that is mathematically or physically not possible. With wishes like these you could the do the planning poker all day and maybe land at a compromise that is still not possible.

As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem.

Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).

Re: "No, it's less effort than that"

#17

Post by nabla9 »

My estimate math:

R = t × [1.1^ln(n+p) + 1.3^X]

R - time it really takes.

t - shortest possible time it would take without need to communicate.

n - number of people working and involved during the process, both customers and developing organization.

p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)

X - number of new tools, libraries, techniques, used in the process.

Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.

2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.

Re: "No, it's less effort than that"

#18

Post by luibelgo »

nabla9 wrote: post #17

My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniq…

Out of curiosity, how did you came out with this formula? What’s the math behind it?

Re: "No, it's less effort than that"

#19

Post by maccard »

pydry wrote: post #13

If you're asking for estimates from devs at all you're probably pushing waterfall on them. If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.

That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
Post reply on HN