"No, it's less effort than that"
smartguess.is
"No, it's less effort than that"
1–10 of 388 posts
Re: "No, it's less effort than that"
#2[deleted]
Re: "No, it's less effort than that"
#3Pushing estimates is silly. If you have another estimate than your developer you have every right to have it and make decisions based on it. But the reality of how much it will actually take is the future. It is unknown and will probably worse than both your estimate and the one of your developer you don't agree with.
Re: "No, it's less effort than that"
#4Pushing estimated is wrong but solutions exists in a spread of quality, completeness and efficiency, you can definitely find a balance where the time to release is shorter, if you are prepared to give up something else
Often the issue is that programmer are unaware of the exact quality and sophistication expectations and estimate the perfect solution with the most efficient algorithmic complexity whether it makes sense or not for the business scale and the other constraints at hand.
Then management ask shorter deadlines, programmers find different solutions that may or may not be appropriate, and it gives the illusory appearance that managing is working, while the underneath visibility/communication issue remains unaddressed while creating potential technical debt.
Re: "No, it's less effort than that"
#5Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
Re: "No, it's less effort than that"
#6It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between.
Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary.
If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.
Re: "No, it's less effort than that"
#7A 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-and-forth as the estimates are questioned for being too high, almost never for being too low.
I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something.
I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.
Re: "No, it's less effort than that"
#8Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
Also any estimate providedwill be pushed downwards, not to mention unforeseen curveballs, so there is an incentive to estimate higher to preserve your own sanity. Some don't learn to estimate higher until they get burnt.
Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.
Re: "No, it's less effort than that"
#9It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between. Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary. If you are asked to change your estimate, see it as an invitation to…
Often clients don't understand what they want; like you say, the difference between met plonking in a basic combobox/select vs some much nicer, and much more fitting the case, custom ui element doesn't really translate to anything many people outside IT understand. To explain this difference it can be drawn, but stakeholders still don't understand what's going on as they don't see & feel it, so you have to make it work mostly.
I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated.
I know the game by now, so these days we make a lot of money from this broken process.
Re: "No, it's less effort than that"
#10I'm glad the article gets to talking and haggling with stakeholders. Trying to estimate with different understandings of where complexity lies between stakeholders, product managers, and devs is the biggest source of frustration in my experience.
Lol, long ago I was working with a junior PM who heard what was difficult and what was easy from devs and started to design features around that intuition to make work faster. Too smart for his own good though. Often the proposed features would be more complicated in trying to be easy. Much to his chagrin, our ticket estimation sessions often turned to "wait, what are we trying to do here again?" But often, one week of work turned into a day or two.
The world is complicated and I think a sizable minority of workplaces defy stereotypes.
One hard driving "VP of Operations" type I worked with would push for aggressive estimates, but alongside that suggested every corner that could be cut without hampering the business. In a bizarre way, he was far more agile/MVP/product-validation focused than almost all of the technical staff.
I've seen fast but sloppy developers drive stakeholders crazy. One situation I was in, we needed to culturally back off from way over-spec'ed tickets. The engineers had been focused on closing tickets and "shipping" as fast as possible. If a detail wasn't in the ticket, it wasn't happening, so tickets got bloated and rigid. The rest of the business was ok with slowing down if it meant reliable features, the engineering leadership was the most hesitant.