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

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

#281

Post by ghaff » Sat, Oct 21, 2023, 6:32 PM UTC

lukevp wrote: post #172

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…

Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people? A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to sh…

>Isn’t sales a numbers game for the most part?

At some level. But numbers aren't created equal and sales reps aren't usually supposed to be calling numbers out of a telephone book. Depending on the type of sales rep, they're hopefully reaching out to people who have been qualified to some degree. The email I got from a sales rep at my own company on Friday afternoon asking for a call about my requirements? That wasn't a well-qualified lead for whatever reason. (Not their fault; I'm sure they're just working from a list.)

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

#282

Post by Tabular-Iceberg » Sat, Oct 21, 2023, 6:35 PM UTC

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've definitely seen devs assume too much needs to be done

Absolutely this, and managers and pseudo-managers like product owners, business analysts and full-time scrum masters do too. I see a lot of weird requirements, often technical in nature, that nobody actually asked for, it was just a long string of people who just assumed. Like an infinitely scalable microservice architecture with a full SPA just to let a dozen internal users download some data as an Excel spreadsheet.

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

#283

Post by ghaff » Sat, Oct 21, 2023, 6:42 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.

>What’s the incentive for a developer to inflate their estimate?

Under-promise. Over-deliver. I'm not doing software development most of the time but it absolutely works out better for everyone concerned if I get things done on or ahead of schedule without mostly having to resort to a lot of unnatural acts to do so. If there's a real need for something faster, I'll tell people I'll do my best and (usually) I can get there absent blockers from dependencies. But I try to manage things so that I can meet/beat estimates sanely. It probably helps that people think I work quickly even given some sandbagging.

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

#284

Post by iimblack » Sat, Oct 21, 2023, 6:54 PM UTC

kayodelycaon wrote: post #184

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 feel this pain, I really do. I want to turn around to fix quickly. The problem is unless you have fully-automated continuous deployment, 30 minutes is not 30 minutes. That 30 minute task needs to be vetted to ensure it doesn’t affect other departments, then it needs to be scheduled, announced, and deployed, which may involve 2 to 3 other people. As a scheduled task it’s closer to 2 hours across multiple people. As…

This is way too true. So many quick changes or fixes at my company have caused incidents, confusion, and more. That 30 minute fix quickly balloons into days of work and unhappy clients.

Even things that don’t blow up on those have so many hidden costs people don’t think about.

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

#285

Post by Detrytus » Sat, Oct 21, 2023, 6:57 PM UTC

replyifuagree wrote: post #248

bloopernova wrote: post #207

Earlier quoted context omitted.

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.

>Only work on the project half the time, spending the other half on something more worthy/interesting. This is actually a pretty common motivation for devs who work under legacy management.

And those who, thanks to WFH can handle two jobs at once.

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

#286

Post by latency-guy2 » Sat, Oct 21, 2023, 7:05 PM UTC

wkat4242 wrote: post #120

jeltz wrote: post #100

Earlier quoted context omitted.

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.

Nobody cares about doing things right anymore. They just want quick wins. Meanwhile all the tech debt piles up.

Seeing as there's tech debt from 40 years ago people like me are still paying, seems like devs don't know how to do things right at all.

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

#287

Post by Arcanum-XIII » Sat, Oct 21, 2023, 7:06 PM UTC

smokel wrote: post #270

I'm sometimes a bit ashamed of the IT sector as a whole. I have been programming professionally for more than 20 years, but I have not seen much improvement in time to delivery. For each step forward, we seem to be taking two steps back. I can't blame the developers, but I wonder who to blame instead. The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, w…

Honestly, the complexity of most systems I've worked on those last 15 years has only grown. Everything require umpteen libraries to show a char on screen (and be inefficient at that). We're still blocked in the 80's for a lot of protocols because of backward compatibility with a ton of hack on top of it. We have built tool on top of other tool to manage the mess we've created, that no one understand at the end.

That's where we're losing time. Dealing with an inherited mess.

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

#288

Post by gardenhedge » Sat, Oct 21, 2023, 7:07 PM UTC

ResearchCode wrote: post #144

gardenhedge wrote: post #139

Earlier quoted context omitted.

Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.

Planning too often is also a problem. You should not do it more often than every three to six months.

Hello waterfall my old friend. How have you been doing?

But seriously.. there's levels to planning. There's strategic planning which is less often and then implementation of delivery stages which is more on going. It is helpful to know if something will be delivered in 2 weeks or 2 months. The problem is when the dev team says 2 weeks but discovers more and knows it will be 6 weeks but the deadline is firmly set to the initial 2 week estimate.

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

#289

Post by latency-guy2 » Sat, Oct 21, 2023, 7:10 PM UTC

ResearchCode wrote: post #133

Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.

Probably because software engineers are not mathematicians. Also, you're not doing foundational research or breaking away at the edge of human knowledge either. Similarly, mathematicians are not immune to deadlines either.

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

#290

Post by Too » Sat, Oct 21, 2023, 7:11 PM UTC

Did anyone ever get asked to simply make the estimate lower? Without any other context? That never happened to me, it sounds extremely immature.

Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”.

Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.