"No, it's less effort than that" • Hacker News Board

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

#51

Post by throwaway091ba » Sat, Oct 21, 2023, 11:26 AM UTC

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, and that's how you end up with unrealistic estimations.

I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.

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

#52

Post by IanCal » Sat, Oct 21, 2023, 11:28 AM UTC

atoav wrote: post #16

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

Always a good time to rewatch the expert: https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl

> most people are okay at describing their problems, but suck at proposing solutions

Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.

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

#53

Post by rightbyte » Sat, Oct 21, 2023, 11:35 AM UTC

ejb999 wrote: post #11

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

Ye. If the estimates are accurate they will be overrun about 50% of the time. Punishing "late" tickets is what leads to the outcome of having to pad the estimates as much as possible.

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

#54

Post by IanCal » Sat, Oct 21, 2023, 11:44 AM UTC

BlargMcLarg wrote: post #45

IanCal wrote: post #35

Earlier quoted context omitted.

I mean it is literally the issue that planning poker addresses - identify differing expectations without influencing the initial estimate. People can then totally ignore that, and ignoring something makes it pointless, but that's true of literally anything. It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move…

That still doesn't solve the prerequisites being exceedingly rare in most teams. A system solving an issue under rare circumstances is barely worth considering, doubly so if it doesn't solve the issue in your specific circumstance. That's, again, disregarding that the modus operandi of most management teams directly interferes with planning poker itself (high turnover, high focus on increasing scope and scope per per…

I honestly do not understand what you're describing as the prerequisites.

You ask people how hard something is to do, make everyone actually answer before hearing others opinions and if people disagree you talk about it to understand why. These are all short term features.

The two things it deals with are:

* get everyone to say how big of a thing it is, find out if there's misunderstandings about what the task involves

* avoid people from being influenced by the fastest to answer person

That's it. It's a very basic communication tool.

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

#55

Post by dlahoda » Sat, Oct 21, 2023, 11:46 AM UTC

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

why shorter is always better than longer?

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

#56

Post by geraldwhen » Sat, Oct 21, 2023, 11:47 AM UTC

bsenftner wrote: post #42

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

This is why Professional Communications is so critical for software developers, and exactly why your manager absolutely does not want you to have such skills: you'll be able to explain why their requests are manipulative, unrealistic, and frankly pointy haired wishful nonsense.

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

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

#57

Post by taneq » Sat, Oct 21, 2023, 11:47 AM UTC

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

The missing link here is to separate the estimate from the quote. Don’t try and make devs estimate lower to win a job, have them estimate honestly and then if there’s a business motive to bid higher or lower, record that separately.

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

#58

Post by verve_rat » Sat, Oct 21, 2023, 11:49 AM UTC

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

I agree with all the points you've made, but I would add that the PMs and managers and directors and whatnot are never that keen to help engineers out on this front.

It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy.

But I can count on one hand the number of POs, directors, managers that want to engage in that conversation with developers. Most of the time a solution is thrown over the wall and developers are told to build a thing.

An actual conversation about a business problem between the people that actually have the problem and the people that will build the software that (hopefully) solves it happens way, way less often than it should.

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

#59

Post by bsenftner » Sat, Oct 21, 2023, 11:50 AM UTC

geraldwhen wrote: post #56

bsenftner wrote: post #42

Earlier quoted context omitted.

This is why Professional Communications is so critical for software developers, and exactly why your manager absolutely does not want you to have such skills: you'll be able to explain why their requests are manipulative, unrealistic, and frankly pointy haired wishful nonsense.

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.

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

#60

Post by GoToRO » Sat, Oct 21, 2023, 11:53 AM UTC

If you ask for a lower estimate it means that you are providing an estimate. Why people that are not qualified to estimate, scum masters, team leads, product owners, provide estimates? The whole management structure is upside-down and then we wonder why software is crap and people quit.