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

81–90 of 388 posts

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

#81

Post by regularfry »

nmstoker wrote: post #69

I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even s…

I think there's an important detail you might have left out of your 30 minute example: are you asking for how long the effort on the specific task will take, or what the time gap will be between right now and the moment it's delivered? Because in almost all teams both are dominated by the task waiting for something, but in the latter case it's especially true. Actual hands-on-keyboard time is usually a rounding error compared to coordination and scheduling. Unless a team has put hard work into unintuitive ways of working, the average ticket will spend grossly more time waiting than actually being worked on. Not only that, but the team will be completely blind to the imbalance, and won't realise it matters.

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

#82

Post by tyingq »

danaris wrote: post #74
tyingq wrote: post #68

Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.

But unless that 3rd party code, and those services, have already been discovered, evaluated, and learned by that particular dev team , integrating them might take more time than building something from scratch that meets the specific requirements at hand. And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs e…

I wasn't suggesting that example was a magic bullet. Just that it is one of many choices that drive an estimate...down OR up. I agree there are cases where 3rd party software doesn't help. I think it would be pretty rare for a team to have zero choices in their control that would change an estimate.

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

#83

Post by pydry »

maccard wrote: post #44
pydry wrote: post #22

Earlier quoted context omitted.

Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.

> relative sizing are not estimates. Relative sizing is still an estimate. > They're for re-arranging the priority of stories and deciding which ones to do or not. Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.

>Relative sizing is still an estimate.

Not one which would attract any pressure.

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

#84

Post by sokoloff »

someguydave wrote: post #43
BlargMcLarg wrote: post #28

Earlier quoted context omitted.

>but this is the issue addressed with planning poker. It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given.…

If people are unable to solve the problem themselves but instead defer to someone else’s estimate then they should not be participating in planning poker

They shouldn’t be bidding, but participating to answer clarifying questions or discuss tradeoffs seems healthy.

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

#85

Post by beremaki »

throwaway091ba wrote: post #51

Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time,…

Most the time the only thing devs are allowed to interact with on the business side is a product/feature proposal with all assumptions already made.

If devs do not know the customers/users nor interact with them then they can't really argue about the proposal's assumptions, it defacto becomes a demand.

With experience devs see such proposals with skepticism. A significant amount of our output ends up being useless, no matter how fast or well it was built.

If you want devs to focus on value creation you have to make it their job, they have to take ownership of the whole thing. When a dev can help a user or a customer they tend to feel fantastic about it.

But truth is business people think devs are inept at doing that so most companies are structured in a way where the only agency devs have is how much time they have to do something.

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

#86

Post by sokoloff »

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…

Why does zero new tools (X) add time?

Alternatively, why does one new tool add so little time?

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

#87

Post by School-Cotton »

bsenftner wrote: post #59
geraldwhen wrote: post #56

Earlier quoted context omitted.

Your workplace may be toxic. My manager celebrates simplification and cost reduction when it solves business problems.

Completely different topic. I'm not even referencing "my workplace", I'm talking our entire industry.

Then you’re just empirically wrong. I’ve never had managers who didn’t want me to have professional communication skills in the ten years I’ve been in our industry.

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

#88

Post by regularfry »

gherkinnn wrote: post #20

The following point has stuck with me for half a year now. > What they actually want is "the earliest date you cannot currently prove to be infeasible" https://news.ycombinator.com/item?id=35318124

That echoes the book Waltzing With Bears, if I'm remembering it right.

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

#89

Post by smolder »

jongjong wrote: post #25

Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.

You could spend 15 years cutting every corner imaginable as a self-professed genius 1-man engineering team until everything becomes unsustainable, feature work is impossible due to frequent fires, the business is faltering, and you can't even understand your own code any longer. Then, quit as soon as a new hire comes in so you can't be held accountable for your quagmire by other engineers. I don't really understand why someone would do this, but I recently got to see it first hand. ;)

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

#90

Post by bsenftner »

_a_a_a_ wrote: post #71
bsenftner wrote: post #59

Earlier quoted context omitted.

Completely different topic. I'm not even referencing "my workplace", I'm talking our entire industry.

Please don't generalise or you wipe out the occasional good that does exist.

Now seriously, my comment is a call for people to acquire professional communication skills, because they are extremely useful when negotiating work in far too many areas to count. Such advice getting down voted indicates how little value quality communications has within the software developer community - to the industry's demise. Communications are everything, and if you don't have good communication skills you get overlooked, abused, and misunderstood... leading to career frustration, stagnation, and burnout.
Post reply on HN