Live data from Hacker News

"No, it's less effort than that"

smartguess.is

291–300 of 388 posts

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

#291
post #244

Earlier quoted context omitted.

Sometimes, but not always. I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook. But when I've been the manager pushing for smaller estimates, it's been because the business realities we…

If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas". You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"

I agree with this. Incidentally, some of my most productive periods were when the team was given a real deadline. Often times either the deadline is made up entirely or there’s a generally understood sense that it can easily be pushed back. I find that if I can trust that the constraint is a real one it really helps us to scope things out of necessity. My theory is a lot of the never ending development cycles is because engineers don’t actually believe the constraints are hard, which leads to scope creep or at least the development getting stretched out.

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

#292

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…

Yeah, this part is getting lost and there's a lot of apologists here. One of the oldest tricks in the book is to create a vision, make a promise, and then say "I did my job, now engineering just has to do theirs"

I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!

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

#293

Earlier quoted context omitted.

[flagged]

One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks. An example of IT work is installing MS Office on a laptop by hand. An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.

Hell, business types confuse data entry work for dev work.

It's Computer Stuff. It's all the same.

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

#294
post #290

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…

TLDR - Yes, but from a crazy person.

Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment:

1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine.

2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head.

3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails.

That was an exciting few years, I have to say.

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

#295
post #11

Earlier quoted context omitted.

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

How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.

In my view, it's fine if it's not treated a performance metric, for the individual devs.

I saw a lot of questionable tactics stem from this. It's like when you play capture the flag, and focus on the "KDR" metric, as is often done.

Critical people who were saving the teams life and working their fucking asses off would get grilled and questioned; not intentionally, but as a natural extension of these processes. Meanwhile, people that scored easy points would get a pat on the head, then sit silently during the sprint review; thankful that they got the easy path this sprint.

It got to the point of absurdity. I think it could make sense to look at sprint points during planning, but then the total bank of points goes to the team; who scored what should be anonymous... this was one of those ideas you have that you know you can never share, lol.

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

#296
post #265

Earlier quoted context omitted.

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

> Not sure what I would do if I didn't have a decent VP! Learn how to actually do your job? It’s always interesting to see toxic positivity painted in such a favorable light. Very glad I don’t work with you.

If you are like most business people I've worked with, you love my complicity.

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

#297

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.

Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.

Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.

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

#298
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…

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Depending on the economic climate and the situation of the company in the marketplace this may be accurate. If you've got good sales people that are already selling as hard as they can't you won't be able to squeeze much more out of them if the economy tanks and nobody wants your product. I'm sure there are sa…

Heh, have we already forgot what happened with Wells Fargo? We need to upsale 10 accounts a day? Random accounts it is!

https://www.justice.gov/opa/pr/wells-fargo-agrees-pay-3-bill...

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

#299
post #290

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…

Oh yeah. Sales sets the ship date, which is 'set in stone' because of a trade show. PM makes a schedule that makes the ship date. PM shows the schedule to engineering and is told it's not possible. PM tells management what engineering said, and management tells the PM to make it work, we need to give sales what they need. Oh, and you can't add more engineering resources, the project isn't that important. PM tells engineering to 'make the schedule work' and we add time to some tasks, but then necessarily take time from other tasks. Then engineering starts the death march, with everyone dreading the inevitable escalation of complaints about the project being late. Start slipping schedule? Let's have a bunch of meetings to rearrange the schedule so we can pretend for a week that we're not behind and let the PM feel good when he gives the weekly update to management.

Of course there's blame on the engineering side of the table too. We chronically underestimate effort, not adding enough margin for unknown-unknowns. So we start working late. Sandbagging estimates. Telling the PM whatever he wants to hear just to end the meeting and get back to work.

Impossible schedules are toxic for people that care, and encourage apathy as a coping mechanism. If you put in a Herculean effort and ship on time you did what you said you were going to do, what, do you think you deserve a cookie or something? The other option is failure. Even if the PM or management isn't upset, engineers still feel the failure of not hitting a goal.

Engineers need to feel wins. Always shipping late because of impossible schedules means no project is a win, no matter how good the design is.

At a former job I found out after a couple years that impossible schedules was a business strategy by the c-level execs. It encourages engineers to work as 'efficiently' (i.e. as much) as possible. God forbid we clock out early because we're not stressed out about being behind. Learning that made me shift from caring to apathy. I left shortly after, but I wish I had stayed a bit longer, it might've been nice to have a job that I didn't care about so I could focus on other areas of my life.

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

#300
> Next time, when someone starts a conversation about your team's estimate, pushing for a lower estimate without any new insights that will lower the effort, ask them: do you ever tell the meteorologist it isn't going to be this bad weather tomorrow?

I'm more direct. I ask them why. As in "why do you think it's less work / time / effort?". Every single time they've realised it's not less, they just _want_ it to be less.

Post reply on HN