Alternatives to using estimated development time for performance metric
Posted by Canadian_Invest0r@reddit | ExperiencedDevs | View on Reddit | 19 comments
Management is implementing a new system for estimating development time in tickets.
Basically, every ticket has an estimated number of hours. The developer has X number of hours to adjust the estimate. After that, the estimate is set in stone. This was specifically asked for by the CEO.
The issues with the new system is that, because we are working with a large legacy codebase, ticket times can sometimes be unpredictable. Often times, unforeseen issues will arise after the timeline to adjust estimation.
We also have issues where the estimates are asked too early in the process, often before a developer has even had time to start looking into the implementation. Furthermore, developers are often pressured to lower initial development estimates by the team lead or other management, even though those stakeholders usually have limited knowledge about the depth or complexity of the changes. This often leads to projects that go over the estimate or cases where developers will intentionally overestimate the time, both which are frowned upon by management.
But worst is that I've heard that management is considering using the accuracy of development estimates as a metric for annual performance evaluations. Ironically, I think this may reward developers who work on small projects over developers are work on large large scale projects.
I've pushed back a little bit on this process, but have gotten flack from management for doing so. What are some good alternatives or improvements to the existing process that management will have an easier time swallowing than "this is stupid"?
Fair_Atmosphere_5185@reddit
The estimate is just an estimate.
If you are constantly off - you clearly are being too optimistic.
Management should not be pushing back on estimates being too conservative. That is something worth addressing with management.
I don't see any issues with the rest of the process
Steely1809@reddit
I like the idea of adding a confidence level to the estimate.
revolutionPanda@reddit
Worked with a manager who always pushed back on estimates. Made all the devs give shorter estimates which weren’t accurate so we missed all estimates. Really making them useless.
geon@reddit
Management trying to lower estimates is extremely stupid. It’s not like the actual work becomes any quicker by underestimating it. So they just set themselves up for failing.
Fair_Atmosphere_5185@reddit
The only reason that management will push to reduce estimates is if they don't trust the engineers to actually be working during much of the stories estimate.
Which could be true. Or not. It's hard to gauge that as an outsider.
akl78@reddit
Better to model that as a drag factor. Then you can manage it better too.
akl78@reddit
Absolutely.
One of the most effective dev managers I worked with had a a spreadsheet he joked about being. a secret weapon but was actually really simple; it modelled our company’s estimated vs actual amounts. Then there was a feedback loop where that became a correction factor on work.
Over a few years, that factor trended down quite a bit!
ZukowskiHardware@reddit
Things running in prod that affect customers. Deployments that make the team faster.
marzer8789@reddit
Estimates are a meme, and your CEO is a moron. Just pad the numbers out the ass then be the hero when you come in under them.
corny_horse@reddit
I mean, the inevitable outcome here is that people will generously pad estimates and then NOT TURN IN WORK until the pad has been completed and matches their estimate exactly
flavius-as@reddit
Ask the CEO what the goals are with these estimates, so that you can meet those goals.
Then weaponize that.
rover_G@reddit
When management wants estimates to become deadlines, increase estimates by at least 50%
rayfrankenstein@reddit
Your management are maximally bad actors acting in maximally bad faith. The horribleness is the point, and your management knows exactly what they’re doing. There is not convincing bad hombres.
You need to refuse any attempt lowering of estimates. Tactfully tell your company that if they want you to work 80 hours a week, they need to explicitly ask it. It’s a hill to die on.
Keep on triple-padding estimates, even if they do frown on it.
Your lead can’t be trusted, so any kind of collision with them to improve the codebase isn’t possible.
You have a commitment to survive, not to maintain quality. Do whatever you have to do to get the job done, even if that means cutting corners..
dantheman91@reddit
Ask them what they really want. If my engs are being graded on estimates, i will over estimate. Otherwise I will try to do my best to give accurate ones. You can't both expect the system to not be gamed and graded on it.
Ideally you should measure them on overall output and success of a project, not how accurate an estimate for a given task was.
da8BitKid@reddit
DORA. Who gaf about estimate and tickets? What counts is how fast things are deployed. That they're deployed, and are error free, and if they're not error free how fast to remediation.
SeniorIdiot@reddit
WTF did I just read? Oh, yeah - totally clueless, uneducated, out of touch, disconnected, penny-pinching, pencil-pushing, narcissistic MBA morons that have no fucking idea what they are doing!
Tell them that!
On a more serious note... the classical thing in where management keep asking for a revised estimation until they hear the magical number they want - and then make it a commitment they'll hold you to when it inevitability fails. It's the same history repeating itself for 40 years. Oh, and even better - I bet the collaboration will be really great if people are rewarded/punished for hitting arbitrary dates. Good luck having colleagues help you when you're stuck. I feel sorry for you; you've already lost unless the board fires the CEO on Monday.
PS. It's Friday, I'm an old fart and I've been fighting management for things like this for 17 years. I need to retire.
lasooch@reddit
CEO clearly doesn't know what they're doing.
Estimates are estimates - hitting or missing them is not a metric of performance, it's a metric of estimate accuracy.
When they become a metric for performance, it means people will game them. Oh, I get brownie points for delivering under the estimate? I'll just double my estimates.
Estimates also become completely meaningless when management pressures lowering them. I'm the engineer here - if anyone has a rough idea how long something will take, it's me, not he boss who may not even be an engineer and even if they are, they are likely too far removed from the codebase itself.
Management can propose deadlines. Engineers can then tell them whether those deadlines are realistic at all and what may need to be cut in order to hit them. The deadlines will still sometimes be missed because accurately estimating anything past a few hours is nigh on impossible.
Not to mention that being under constant pressure to hit an unrealistic estimate also means cutting corners in unplanned ways (i.e. instead of upfront deciding that feature A will be dropped, you end up introducing bugs in the feature that isn't dropped, because you lack the time to properly design/test it). It's typically more expensive to fix things than to get them right in the first place.
Idk if this helps at all. Maybe you know all of this already, maybe something here gives you a new argument.
But if pushing back doesn't work, I'd honestly probably just start looking for a new job. If management doesn't respect your expertise that they hired you for, it's not a good place to be.
rlbond86@reddit
Unfortunately ypu are going to have a hard time convincing a non-technical CEO that they are asking for the impossible. The solution here is to 3x your estimates. If they ask for the estimate too soon, first make a story for initial research. Start coding during this time. The artifact you produce should be an estimate to finish the task.
The problem is, while it is often difficult to come up with reliable estimates, the business is still a business and they operate in weeks, months, and years. It's not unreasonable to ask engineers to do their best to estimate development time, but they do need to be able to understand how much uncertainty is in each task and what the risks are.
It's also important to realize that estimates aren't static. If you estimate 3 weeks for a task and then discover new information that will double the task time, let your management know and you can revise the estimate. A good manager won't let you get skewered due to initial estimates (so hopefully yours is good...)
abrahamguo@reddit
It sounds like you need to have a deeper conversation with leadership to understand their visions and expectations.