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

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

#201

Post by 23B1 » Sat, Oct 21, 2023, 2:48 PM UTC

lmm wrote: post #80

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

> developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate I put plenty of effort into trying to understand. 95% of the time there's no business reason. Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense. Sometimes the business wants to decide whether to do thing A or thing B (in which cas…

> Most of the time someone just wants to put a number on their powerpoint for some organisational politics nonsense.

Yes. Thats how coalition-building, budgeting, and reporting works in business. Not saying it should dominate your schedule, but it's just how organizations work. Engineers/Developers are part of the org – not some special snowflakes that are above or beyond politics.

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

#202

Post by paulcole » Sat, Oct 21, 2023, 2:50 PM UTC

replyifuagree wrote: post #199

paulcole wrote: post #175

Earlier quoted context omitted.

There’s a consistent belief here that Programming Isn’t Like Other Work™ and that you can’t estimate it, it’s so mentally taxing that you can’t do it for more than a few minutes at a time in complete silence, and that it’s closer to Da Vinci sculpting the Sistine Chapel than kludging together a few APIs. It’s fun to think you’re special and easy to do when you’re paid a shitload of money.

Programming is like some kinds of work. It is very much unlike operating an established manufacturing facility. But, about two thirds of dev work has a lot of parallels with creating a new manufacturing facility that manufactures a new kind of thing using new materials and techniques. The primary parallel is that a new facility requires a lot of discovery. Whereas if operating an existing facility constantly required…

[flagged]

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

#203

Post by replyifuagree » Sat, Oct 21, 2023, 2:50 PM UTC

epolanski wrote: post #193

jalapenos wrote: post #159

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…

I swear I hate this estimates thing so hard. For many reasons: 1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway? 2) There are no incentives for teams ultimately to estimate…

Yeah if you estimate realistically many companies have a culture that will punish you for not being a team player.

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

#204

Post by qingcharles » Sat, Oct 21, 2023, 2:57 PM UTC

bgribble wrote: post #91

masklinn wrote: post #72

Earlier quoted context omitted.

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

“Everyone has a plan until they get punched in the mouth.”

The problems with precise specs is that they miss all the dozens of edge cases and gotchas that don't crop up until you actually try to code them. Then you need smart, imaginative devs to ignore the specs and write something that people can actually use.

I've worked with devs who write _only_ to the spec and never diverge at all, regardless of outcome, in order to check off boxes and make their managers happy. Their work sucks.

(this might not apply if you are writing code for moonships)

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

#205

Post by replyifuagree » Sat, Oct 21, 2023, 2:58 PM UTC

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…

Yep, these days I tend suss out the estimate the person is looking for because the relationship is actually more important to my career longevity. I mean, the estimate is very likely wrong anyway, so they might as well be happy for a bit!

This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.

There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!

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

#206

Post by 23B1 » Sat, Oct 21, 2023, 2:59 PM UTC

My favorite bit of this argument is the presumption of honesty, accuracy, or transparency on the part of developers. Someone in the estimation process is always protecting themselves, packing on a little margin, or fudging the numbers. It's nothing to get upset about, it's just normal human behavior, happens in all industries.

For this reason alone, I always kick estimates back down and amazingly they almost always come back better-optimized – usually because some trusted graybeard engineer, who has been on both 'sides' of the business, steps in and cleans it up based on his experience.

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

#207

Post by bloopernova » Sat, Oct 21, 2023, 3:01 PM UTC

jnovek wrote: post #187

corry wrote: post #167

“Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unkn…

It’s not at all like sales quotas. The salesperson’s upside is directly linked to their quota, they are incentivized to fudge it as much as they can. What’s the incentive for a developer to inflate their estimate? The only reason I have to inflate an estimate is if I know some non-engineer boss-type is going to swoop in and try to convince me to lower it.

Incentive to increase estimate might be:

Deliver under estimate and get a bonus, raise, influence, or just plain old "well done"

Be lazy and only work half the time while delivering "on time".

Only work on the project half the time, spending the other half on something more worthy/interesting.

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

#208

Post by justin_oaks » Sat, Oct 21, 2023, 3:02 PM UTC

Estimates aren't deadlines. If we're talking estimates then we should also talk about accuracy and precision.

I can give a low estimate if you're ok understanding that it's not a deadline and that is has astonishing low accuracy.

Estimates indicate that there's a probability that the time required could be more OR less. Choosing the deadline to be exactly the same as the estimate is ignoring the probability that the the task will take longer.

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

#209

Post by 2devnull » Sat, Oct 21, 2023, 3:02 PM UTC

jalapenos wrote: post #159

It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - s…

But it’s easy working for such people once you identify them. They are “goes to 11” people. Like that amp in spinal tap you just make your regular output max level be a 9, then you have room to go 1 more when they want you to. Of course that means working slower than you otherwise would. But if they want a dev that “goes to 11” it’s pretty obvious to some of us that there’s only one way that works.

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

#210

Post by dsego » Sat, Oct 21, 2023, 3:03 PM UTC

crucialfelix wrote: post #124

dsego wrote: post #97

Earlier quoted context omitted.

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.

Also some designers throw in too many features because they want to fill space in the design.

I think they want to be helpful and leave their mark, which sometimes includes trying to reinvent boring CRUD designs and borrowing some cool but more involved ux pattern they saw in a big-money product. Adopting a popular 3rd party component library sometimes helps, but for some reason it's hard to push back on tweaking the behavior of these components all the time, and usually those component libraries are such that they include everything but the kitchen sink, well... except that one thing that the designer is insisting on. And that one is really hard to do with that library and takes way more time than anticipated. The value-add here is in my experience almost always negative. Looking back at delivered projects, I can't shake the feeling that involving designers at a later stage would be beneficial to the project and timelines.