they do get paid more.
I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.”
Two years later I learned they were still working to finish it.
Another example: they wanted a Byzantine Fault Tolerance rewrite along with the networking layer. I said we need 6 months. They said we know how it should be done in 1-2 months. I finished my stuff and moved on — they picked couple of people to work on the rest that had said 1-2 months. It took them a year to reach a point they could test it.
Now why did I say 6 above? Because that is a project I have done multiple times, I can do everything in my sleep and the delay beyond all other fundamentals is random interruptions. Did that matter? No.
When top head works with wishful thinking estimates are ways to find scapegoats; nothing more.
Time estimations are bargaining, you ask for something and then get a counter offer from management, they don't care that the counter offer from them is delusional. The bargaining is the point, the less time you bargain for the more stressful the development can become. Don't estimate what it should take, estimate what it could take and bargain from there.
People that were fairly technical prior to deciding to move to PM roles, those you can actually explain the context and reason with.
PMs that are more biased towards Business/Marketing are big on C Level networking etc., those are the ones that feel they are doing a good job if they try to bleed a stone with deadlines. They are adversarial like GP mentions and not someone you can reason with.
These are the kind of managers I will go the extra mile for. Got my back I got your back and make sure you shine.
Allow me to indulge in a fictional narrative:
You are handed "high level" (a.k.a rooted in the fuzzy non-technical alternate reality that is product management) requirements resulting in known unknowns and unknown unknowns. You're junior and naive and you put real tech-borne effort numbers in front of each task; or you're experienced and you put O(t) numbers on the first ones and random but high numbers on the second ones.
Anyway, the estimates end up landing past the desired deadline, management mutters TLAs such as "OKR" and whatnot, you'll have to justify why it doesn't fit, so you communicate work effort.
You are summoned into a retroplanning meeting to cull out stuff based on work effort so that it fits management's expected deadline, and try to pretend you're doing agile when it's all waterfall Gantt in disguise.
Project starts. Implicitly man-hours become wall-clock-hours, irrespective of other tasks such as CI/tooling/dependency breakage, code hygiene, or customer support escalations; your effort estimates became t{project start}+effort == deadline. You are now held accountable for the latter based on you communicating the former.
Time is now the scarcest of resources, you do your best, conjure magic, work extra hours, take shortcuts, and make it to the deadline, sacrificing body and soul. In a cloudy spreadsheet checkboxes have been checked, management is happy. Deployment is smooth but soon corner case bugs and escalations start trickling in. Management is either oblivious or not so happy after all.
Time for a new quarter to start. You know issues borne out of past quarter will rear their ugly head, and there's much tech debt to repay before interests quickly accrue towards tech bankruptcy. You're junior and swear to yourself to not make the same mistake, and you start inflating numbers; you're experienced and you realise the whole number dance is a sham as they don't matter anyway, but you still are required to do the dance because that's how the game is played, so you turn Scotty and just throw outrageously big numbers up in the air and just make sure the deadline is not too ludicrous, still hanging to the hope hoping that someone, somewhere, has seen the light of reason and built a company around it, and maybe you could go to these greener pastures; you're very experienced and you realise the only winning move is not to play, so you quit (not the job, the _industry_) and move to a remote plot of land with literal green pastures and a small cabin mountainside to raise sheep, or cut wood, or whatever, where the smallest time unit is the measurement error of eyeballing the zenith-relative angular position of a giant fireball 8.3 light-minutes away.
Also if someone’s estimates aren’t perfect, that’s something you can use to justify withholding salary. The game is fixed. It’s just a good deal less fixed for us than for the average person.
Management might not be so dumb. If someone said 2 months and you say 6 months, they might go with the person who said 2 months but will accept 5 months secretly.
If it’s a conspiracy not everyone is in on it, at least. There’s more an element of believing your own PR in many cases.
The 2 month version could be sold at all, the 6 month one can't, so it's not worth considering its technical merits.
Then the client/stakeholder buys in, the sunk cost, well, sinks in, and things get fixed. Success!
In 6 months you need a better scaling version while the current version is creating cascading database failures; it's got terabytes of denormalized data that is out of sync and a 2nd team can't migrate the data in 12 months.
In 12 months, you find 5 other teams copied the 2 month solution.
In 2 years, you have 0 devs left that can solve the problem and a 1000% grown dev team that is great at the 2 month solution.
You ask the teams why they don't use the scalable solution and they say, "do we have any examples of that, the unscalable way is our convention"
^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.
The real problem is saying "yes we can do it all in that timeline" instead of saying "That's fine, but we won't get to everything. We will work with you to prioritise the most important things to get done in that time."
I know it's painful, but just hold that line. It's not lying or negotiating or padding; in fact it may be the only true statement you can say.
If a civil engineer were building a bridge, and couldn't do it safely in the budget and timeline, they'd say so, and the project manager would nod and diligently write that down. We have a more subservient relationship with project managers in software because we choose to.
I'm not sure how. I mean, if I know it takes X time to do something, what would make me to commit to Y<<X time when I know it will fail and will be made my fault? If they want to record it as a deadline, so be it, but if it's an impossible deadline I'd make every effort to be on record that I said it from the start that it's impossible.
The problem is that management unreality can take a decade or several to destroy a place. But when you see that kind of management, know that that's the road they're on. That's your cue to start looking for somewhere with management that at least tries to live in reality.
I think you’re conflating success of a company with the pleasure of its employees. These 2 factors are usually (not always) opposing not correlated.
Then the new organization can say it wasn't because they misestimated, it was just the poor organizational structure before.
Obviously this new structure would have achieved the result in the time allotted.
"hmm, adding that button probably takes about an hour"... 2 days is about right.
Almost 30 years later I still find this to be true. Truer than I like.
And if you're estimating something to the lengths of months, you're already into project management territory size, rather than broken down to development/delivery sizes... The amount of unknown unknowns and other uncertainty certainly warrant happily estimating years length, surely.
Also #NoEstimates (=
- You’ll get a bunch stakeholders each requesting a different format of progress reporting.
- You’ll get pulled into dealing with a small but disruptive emergency that requires unique expertise.
- A dependency will change in a way incompatible with your work in progress.
- You’ll hand off the half done project to the new hire.
- You’ll need to rediscover what the project is about after the new hire hands it back.
You don’t want them interacting with you too often for one hour tasks. You want to train them to lower resolutions slices. And you want to round up small ones to do refactoring as well.
Eventually they get a sense of just right. It’s never perfect but they are estimating before they even ask. Whic if we’re honest, they’ve done anyway and they’re hoping we will agree, absolving them of the responsibility.
This happened 15 months ago?
(A * B) / C + 2^D + (rand(4, -4) * E) / (0.5 * F)
[B] I have no idea what I'm doing ratio
[C] I totally have done this before
[D] Amount of weekly WTF per code review
[E] That stakeholder couldn't hold a stake
[F] Likely hood of it changing by next week
Property developers aren't doing R&D jobs. Most of software development is a multiplayer life sciences R&D, because even if you're not developing new technology, the combination of your chosen stack, target market, stakeholder personalities and management policies, makes your project a one-off job in an unexplored environment.
- estimate at least 20 days
- multiply by 20
Good luck with that.
+ c constant.
I know you like to complain alot about how your cubicle roommate doesn't understand basic control structures and the difference between floating point and integers, but he, unlike you, always adds story points to the tickets. That's why he's on fast track to lead senior developer. He knows what's important. I'm trying to help you learn what's important too, but you've got to want to be helped.
42 seconds
42 minutes
42 hours
42 days
42 weeks
42 months and my resignationWith negative weights for keyboards with cherry mx blue.
One of the knocks against me in my last performance review was that I had poor time estimation for completing tasks.
I asked my lead for help in getting better at this and they were basically a real life version of the Neil deGrasse Tyson hand waving GIF.
Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it by the room temperature multiplied by the amount of people with mechanical keyboards.
That gives you roughly the right estimate for any job, until the next sprint.