Live data from Hacker News

"No, it's less effort than that"

smartguess.is

211–220 of 388 posts

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

#211
I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building.

A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.

In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.

In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).

Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.

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

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

The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines. You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

How is that different from arbitrarily raising quotas?

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

#213
I link with the article, I usually call predictions a forecast, and not estimates, because you don't get angry at a meteorologist.

I have produced estimates for almost 20y now, and boy do I hate that. There's multiple layers to it.

This post touches the nefarious one. Sometimes yes, someone wishes something would come sooner and will shake the tree to see what happens. Sometimes there's actually a reason for it - be it budget, customer related, event related, etc. Sometimes someone knows better, because the feature or project is similar to another that was shorter.

When someone discusses estimates with an underlying motive other than their experience and surprise at the cost, I usually enter a discussion where I produce the evidence for our numbers and justify what we are telling.

It highly depends on why we produce estimates in the first place. If it's for budget or planning, I couldn't care less to reduce estimate, since these exercises are pointless in nature in my experience (the budget or planning is usually rendered moot within weeks of being approved).

If its to predict delivery dates, I'm usually very conservative, note that I am not in the art of divination, and that reducing estimates is a risk in itself if anything bad happens. When people are acting on bad faith, documenting stuff usually tames things a little. Unless things are very simple and predictable, I also usually provide several dates with confidence indices. This is a framework that's much harder to negotiate, and give some information to whomever "needs" those dates. It helps reducing the pressure a bit while being non committal and leaving room for error (and I never give a 100% confidence).

TBH, I don't think I've ever been in trouble for "being late", especially because I have always been able to explain that we weren't late, we just gave an incorrect date in the first place.

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

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

The difference is that lowering the estimate for a given amount of work doesn't actually get it done quicker - it just means you have a more unrealistic understanding of the timelines. You can absolutely work to find other creative solutions to the same problems, or understand what scope is acceptable to cut to meet some goal. That's very different from "I want you to do exactly the same work but just do it faster".

If your stories are so well defined the dev doesn't have any decisions to make in the process of coding, then they're more of a glorified type writer than a dev.

There's plenty of decisions devs make that impact how quickly they deliver a solution.

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

#215

Earlier quoted context omitted.

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

[deleted]

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

#216

Earlier quoted context omitted.

> I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.

Except a sale is a sale; did they buy it or did they not? There's additional nuance for whether they'll buy again or what support they need going forward, but a sale is still a sale. A program is not just a program. A bug fix is not just a bug fix. They are not fungible, while sales, definitionally due to the exchange of money, are fungible.

Taking a narrow view, maybe. But a sale in a jurisdiction you don’t currently have other customers in could impose significant regulatory burden for relatively little gain. A single 100x sale is very different than 100 1x sales both in overhead you’ll have and in how much leverage the customer will have in the future, etc

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

#217

I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building. A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev whe…

> Engineers have a habit of over engineering

Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely.

Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.

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

#218
post #135

Earlier quoted context omitted.

Ludricrous estimates are usually a symptom of other organizational quirks. I'd compare it to the military's $435 hammer [0], from the outside you'd think it makes no sense, but that's the logical end of a series of processes that all somehwat made sense on their own. A common issue I've seen is devs having to put their head on the chopping block when making estimates. After the second or third time they get seriously…

Oh wow, I had no idea the story of the $600 hammer was still around. This has been a talking point for like 40 years now, and it was a different number when I was a little kid. Turns out the story had been debunked at least 13 years before the article you posted was written, and is 25 years old now. The military never paid hundreds of dollars for a hammer, someone just averaged a bunch of financial R&D overhead and t…

I would not say it has been "debunked".

The stories are real; they're not all "accounting misunderstandings" or what have you.

[1] https://www.airforcetimes.com/news/your-air-force/2018/10/23...

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

#219

Earlier quoted context omitted.

Honestly, asking these kinds of business level questions as a dev is a great way to be seen as stubborn and uncooperative in businesses where the mindset of the OP comment has taken root. The managers who complain about their devs not thinking at the business level are usually the ones shooting them down when they do. Why are the coders questioning why we need the baby?

It might be, if it’s directionless pushback instead of genuine curiosity to understand the need of the internal customer. From my personal experience, people are often positively delighted when you make an effort to try to understand them and their needs. Not shooting down your experience, but from my perspective it could be seen as a straw man argument in favour of never trying in the first place.

I'm not saying "don't try." And I'm also not disagreeing that people, on the whole, respond well to attempts to understand them and communicate with them.

My observation is that it is ultimately organizational culture that frames the way people communicate and how they understand each other. Individuals can move the needle a bit depending on the size of the company and their position in it. But largely they are powerless against the prevailing culture.

In a healthy organization, your efforts to understand the rest of the business and its needs will be accepted as you intend and will benefit yourself, your team and the business. In the average toxic organization, your good intentions won't matter and your questions won't be received the way you intend. Staying upbeat and helpful in these environments might even result in you being punished.

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

#220

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

Meteorologists also don't put themselves in my shoes when I ask for sunshine.

And you'll be happy to know that these days I suss out the estimate the business team wants and give that estimate. Then carve out more time via scope exceptions. Then, because I can't carve out enough time to actually finish, deliver a release that looks finished to a QA team, but is actually riddled with customer operation interrupting performance problems, intermittent crashes, memory leaks and bugs.

Here is the very best part, the business team blames QA for not finding the problems.

Post reply on HN