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

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

#261

Post by dasil003 » Sat, Oct 21, 2023, 5:28 PM UTC

This article is extremely weak, pandering to engineers beset by clueless pointy-hair antics, without acknowledging that engineers can suffer from their own blind spots, regardless of whether stakeholders have the technical background to understand it or not.

The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing.

But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions:

> In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes

Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.

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

#262

Post by badwolf » Sat, Oct 21, 2023, 5:28 PM UTC

makeitdouble wrote: post #137

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 The simplest solution to this is to make them an actual part of your business. Do your lead devs assist business meetings ? do the dev team get the numbers, get a look at the budget, work with you on the roadmap, look at the user research and brainstorm the features with the business and UX people ? If not, why would you expect them to understand th…

Bridging that gap can be difficult. I always try to include leads in business meetings, provide weekly reports on how their work is performing (do users actually like the feature that was built? Is it generating revenue for the company, etc...) I've found teams generally are excited at first, but then immediately start complaining about "more meetings," getting told "You're the PM, why are you asking me, you write the specs"

It definitely needs to be a 2-way bridge, and when both sides can and do come together, great things can happen!

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

#263

Post by nmstoker » Sat, Oct 21, 2023, 5:33 PM UTC

orwin wrote: post #113

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…

Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved. I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done wh…

Understood. I never do unless it were breaking prod or breaking major business processes.

Regular approaches, avoiding firefighting are essential to steady, stable states.

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

#264

Post by nmstoker » Sat, Oct 21, 2023, 5:35 PM UTC

nmstoker wrote: post #263

orwin wrote: post #113

Earlier quoted context omitted.

Don't ask for 30 minutes tasks unless you have to (it's breaking the prod or something), it's inefficient for everyone involved. I'm in a team with a lot of leeway. No one is counting my hours, no one external look at our productivity, but when we're needed, we don't have time to polish our code. When i have a '30 minute' task identified, I put it in our morning review, and ask if something adjacent should be done wh…

Understood. I never do unless it were breaking prod or breaking major business processes. Regular approaches, avoiding firefighting are essential to steady, stable states.

Sadly the need comes up too often.

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

#265

Post by c0pium » Sat, Oct 21, 2023, 5:36 PM UTC

replyifuagree wrote: post #205

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

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

#266

Post by paulcole » Sat, Oct 21, 2023, 5:39 PM UTC

replyifuagree wrote: post #231

paulcole wrote: post #223

Earlier quoted context omitted.

Go to any thread here on HN about WFH, open offices, 8-hour work days, etc. and tell me I’m wrong.

Regarding open offices. The Fed commissioned MIT to do a study on the effect of public observation and found that it significantly reduced people's effectiveness at solving puzzles.

Just proving my point. Significantly reducing some tech bros ability to do puzzles doesn’t mean that private offices are needed to make the 10,000,000th Rails app.

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

#267

Post by paulcole » Sat, Oct 21, 2023, 5:40 PM UTC

replyifuagree wrote: post #227

paulcole wrote: post #202

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.

But yeah thats kinda my point. Integrating VBA into excel isn’t the Manhattan Project. Unless it’s your first job you can probably break the project down into steps and give a decent estimate of time on each.

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

#268

Post by nine_zeros » Sat, Oct 21, 2023, 5:41 PM UTC

23B1 wrote: post #201

lmm wrote: post #80

Earlier quoted context omitted.

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

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

And yet, none of the politicians are going to toil to make the deadline work. There is no gain to be had for the actual engineers or the actual business.

How about this, tie a deadline to a well-defined bonus that only the engineers would receive and staff the project with ALL the engineers you can get. This will allow political heads to keep doing their coalition-building while engineers also receive some benefit for their toil.

If you are unwilling to share the rewards of the toil, it is no surprise that the actual people doing the toil don't care about your coalition-building nonsense that doesn't even help the business in anyway. Your coalition-building vs their own time with family/friends, not a difficult choice to make.

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

#269

Post by marcosdumay » Sat, Oct 21, 2023, 5:41 PM UTC

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…

> “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”.

This would be perfectly true if you replace it for a sales estimate, instead of quota.

The problem here is incompetent managers lying to inexperienced developers to get them into an expensive contractual obligation. It's borderline fraud, and yes, that means working with that manager is something to be avoided.

But going to a developer and plainly demanding him to finish the work on some time can be as perfectly fine as doing the same with sales people.

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

#270

Post by smokel » Sat, Oct 21, 2023, 5:45 PM UTC

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, without formal restrictions, results in terrible security problems. Which have to be fixed. Which takes enormous amounts of time.

The second one is related to that, and that is the idea that we have to continuously upgrade everything to the latest fad. As one consequence, we are somehow stuck with a weird common ground for user interfaces defined by web browsers, which leads to overly complex software.

What most people often want is just a push button to send a message to some other system. Both companies and governments alike seem to be paying billions of dollars for that. Because it is all so extremely complex, and people are somehow buying that.

My understanding is that the industry is happy making a lot of money, so there could be limited incentive to change things for the better. However, for some other odd reason, most ordinary people try to avoid technology like the plague, and pride themselves in not understanding how computers work, yet unknowingly spend a big percentage of their tax money on exactly that lack of understanding.

I am still extremely thankful for the likes of Richard Stallman for starting the free software movement. Unfortunately, delivering software is only one (small) part of the problem. Embedding computers in human processes is a whole different ballgame. Can we perhaps have some kind of "free management foundation" as well?

I actually reread the above rant, and I fear for the downvotes, but perhaps someone understands what I am on about and has a good tip to ease my mind.