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

91–100 of 388 posts

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

#91

Post by bgribble »

masklinn wrote: post #72
paulsutter wrote: post #23

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

> The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions I think it's less simplification and more precision and completeness. Obviously if you have simpler requirements they more complete and precise, but the requirement might not actually be simplifiable. In which case what you want is better specification. "They…

As a developer I hate "precise" and "complete" requirements. Usually these extremely detailed roadmaps are just fairy tales. They indicate a management and product mindset that thinks you can pre-chew a developer's food for them and make things more predictable.

In fact, what you are doing is tying the developer's hands and making it less possible for them to nimbly work around unforeseen obstacles or repurpose existing solutions without raising a "process exception" to reopen the spec or sizing of a work item.

Be clear about the goals but let the developer(s) who have their hands in the code make the decisions about how to implement it. That means you can't really roadmap a big project down to the minute, but those roadmaps were always lies so there is literally nothing lost except for some fantasy Gantt charts.

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

#92

Post by jeltz »

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.

I have met such managers you talk about but from my personal experience they are not a majority. Maybe I have been lucky or you have been unlucky.

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

#93

Post by gedy »

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

> Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side

A big issue is that "business side", including UX, mostly have zero scrutiny of what they spent their time on or when important work will be completed. Whereas engineers get scrutinized about tasks by non-engineers who can't and won't understand.

And frankly, many times this hand-wringing about estimates is because product and UX took way too long to "plan" the work to begin with. So there's some natural resentment from engineers about this.

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

#94

Post by regularfry »

pydry wrote: post #83
maccard wrote: post #44

Earlier quoted context omitted.

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

If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint.

If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.

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

#95

Post by roenxi »

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

Everyone understands that why the business needs to an estimate and that shorter is better than longer. There is no ambiguity there at all. The complaint is the phrasing like the developer can know when it'll be finished. Someone's ability to deliver value quickly is unrelated to their ability to estimate how long it will take. They can get their estimate completely wrong and deliver huge value. And we all know if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators for the same reason that software companies often develop product teams to negotiate what features a product should support. There is no point asking devs to do it. Oh course, no-one else can either and the devs will at least get the lower bound right so people bother them but the process is transparently stupid.

To know how long something will take it is necessary to list all the steps taken to do the thing. That just isn't possible in software development. Developers can come up with a lower bound for a given set of requirements. And I think everyone agrees that they could do an accurate estimate assuming nothing unexpected happens. Then, in 95-98% of projects, the estimate turns out to be under-calling how long a project will take. The "developer estimates" becomes a measure of how much fat the developer feels like putting in the system this project.

Asking for estimates completely misframes the conversation. The question is what problems does the business have now, what problems are likely to develop in 6 months, and some input from the developer on the cost-benefit of trying to solve those problems. Then people make some qualitative decisions with an eye on minimising risk. The best outcome after giving software estimates is that everyone ignores and forgets them - anything else destroys business value.

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

#96

Post by bsenftner »

School-Cotton wrote: post #87
bsenftner wrote: post #59

Earlier quoted context omitted.

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.

You manager wants you to agree to the work they ask you to perform, and they want to load you up with work to maximize your efficiency. How one negotiates when you're reaching capacity is professional communications. If one is unable to attain work/life balance that is due to a lack of communication skills, the lack of the ability to explain you're past ordinary capacity, burning your health. Our industry is over run with members over working - that's due to their inability to communicate the are over capacity.

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

#97

Post by dsego »

paulsutter wrote: post #23

The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule

Oh, but we need the full search functionality right now, yes there are only tens of entries now but in a few years there will be thousands. And the designer will design all the search flows based on our twenty page product requirements doc, and we will include engineering to write stories and estimate the works once it's all planned and prepared.

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

#98

Post by em-bee »

zeroCalories wrote: post #65
Buttons840 wrote: post #30

Earlier quoted context omitted.

> Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. Developers have to push for higher estimates because management has an incentive to underestimate to make life easier. See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natur…

You're reading too much into the morallity. Furthermore how is it a fallacy?

it's a fallacy in that it implies that one side is right and the other is wrong. (or one side is fair and the other is greedy)

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

#99

Post by bgribble »

fasteo wrote: post #21

1975: Fred Brook's wrote[1]: “The bearing of a child takes nine months, no matter how many women are assigned.” Can't get better than this [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies."

EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.

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

#100

Post by jeltz »

sokoloff wrote: post #78
dlahoda wrote: post #55

Earlier quoted context omitted.

why shorter is always better than longer?

Unless you’re in the business of “selling hours”, why wouldn’t having something valuable done more quickly (and thus at a lower expense) be better, all else being equal? Sure, if you’re a contract dev shop who is marking up hours, then longer is better.

From my experience this is simply not true because all else is never equal. Employee burnout, technical debt, risks taken due to rushing, people not doing the right tradeoffs, etc.
Post reply on HN