So happy to work without estimates for decades.
We just work on our tasks until they're done.
"No, it's less effort than that"
131–140 of 388 posts
Re: "No, it's less effort than that"
#132Earlier quoted context omitted.
If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment…
> If you don't think toxic managers and scrum masters If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.
Re: "No, it's less effort than that"
#133Why 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.
Re: "No, it's less effort than that"
#134Why 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.
Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
Re: "No, it's less effort than that"
#135I 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…
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 then someone else took the numbers out of context and spread it around. https://www.govexec.com/federal-news/1998/12/the-myth-of-the...
Re: "No, it's less effort than that"
#136Why 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.
Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
Re: "No, it's less effort than that"
#137Whenever 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 the business ?
The other side of that dev/business separation: as you put it, that creates a holy land of software development, as everyone has their own silo while expecting other specialists to be well versed into their own problematics.
I think many businesses are working dispite extremely siloed roles for their team members, and people tend to think that's an OK way of doing things as money keeps flowing in.
Re: "No, it's less effort than that"
#138Earlier quoted context omitted.
Please don't generalise or you wipe out the occasional good that does exist.
Now seriously, my comment is a call for people to acquire professional communication skills, because they are extremely useful when negotiating work in far too many areas to count. Such advice getting down voted indicates how little value quality communications has within the software developer community - to the industry's demise. Communications are everything, and if you don't have good communication skills you get…
I don’t think you’re being downvoted because you’re promoting improved communication skills. I think you’re being downvoted because you’re implying that managers “absolutely does not want you to have such skills”.
I’d wager portraying an important work relationship as adverserial and manipulative is why people downvote you. It’s a bit of an overplayed cliché with the bad boss.
Ironically you might be downvoted because of what you’re saying being misunderstood, which I guess is to your point.
Re: "No, it's less effort than that"
#139Why 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.
Estimates help planning. The problem is that they often travel through a company and become immovable deadlines.
Re: "No, it's less effort than that"
#140Earlier quoted context omitted.
why shorter is always better than longer?
The OP is talking about business, so having something done in 2 days versus 4 days is always better. Ignoring everything else, less time is less money.
And on the other end, that’s two more days that the company gets the benefit of your new software.