Manager: We (meaning you) need to do task A. How long will it take?
Me: Task A will take X days to do.
Manager: That seems awful long.
Me: How long do you think it should take?
Manager: It surely could not take any longer than Y days.
Me: Ok, it seems you have an answer to your question then.
Later:
Manager: It’s been Y days, why isn’t task A done yet?
me: suggests anything extra not on the critical path but useful
lead: grumble dont bother automating it, just do a manual minimal local fix!!
later same issues appears
repeat local fix * 1000
Nothing is more triggering to me than the question “how long will this take?”
It will take as long as it fucking takes, and you shouldn’t be reporting anything until it’s done. Measure progress by fully working, end-to-end features, not by a number of hours someone pulled out of their asses.
You need to allocate resources and prioritize tasks
If task A takes a day then it might be worth doing. But if it takes 2 weeks then maybe not
I Dutch auction it. Every time the estimate is asked for/confirmed/reconfirmed/queried it goes up.
Dutch auctions are the ones where the high initial price decreases until someone buys the object.
I thought Dutch auctions were where your date and you split the costs of the bid.
I have so much to learn about microeconomics
I thought Dutch auctions were where you force the covers over your SO’s head and let rip.
I’m really sorry this seems to be so common. I’m in a position where my PM accepts the team’s estimate, and even understands it’s just an estimate.
I don’t work in programming (helicopter maintenance/repair), but my boss goes one step further.
Boss: How long until it’s ready for a test flight?
Me: I’d say…
Boss: Wait. Give me an honest number, don’t add buffer time. I’m already going to double whatever you say to tell District.
Me: Oh, okay, with paperwork and ops checks, 3 hours is feasible, as long as we don’t encounter any other issues.
Boss: roger, six hours, sounds good.
I love your boss based on just this. You in private or MIC? I know a Harrier/F35 wrench that I’m trying to get to move someplace nicer.
Military. Search and rescue, specifically.
wait you have a cool boss in military? fuck yeah dude. I’ve got a friend who does medical helivac/SAR for our local government. (or did last i talked to him, he’s one of those friends you reconnect with like twice a decade and no time has passed). it’s my favorite branch of aviation.
Usually:
Manager: We (meaning you) need to do task A. How long will it take?
Me: Task A will take X days to do.
Manager: That seems awful long, are you sure you are using our choice of AI tool correctly? NVM I vibe code that myself
Later:
Manager: Here is my vibe coded single PR with features A, B, F, and some refactoring. I have no idea what it does, could you check that it works? I have no specs, documentation or tickets for any of this and I don’t have time to fix failing CI gates
Ooh yeah, my favourite “I will vibe code it” route :)
I usually tell them that I need to do it to in order to estimate how long it will take next time. next time it will already be done, here it is.
Fun fact, you can play tough too.
Manager: We (meaning you) need to do task A. How long will it take?
Me: Task A will take X days to do.
Manager: That seems awful long.
Me: How long do you think it should take?
Manager: It surely could not take any longer than Y days.
Me: Ok, which features are you willing to remove to make it fit in this timeframe?
It’s surprisingly effective, especially with a bit of seniority.
Haha! Yeah, I do this with requirements creep:
- Can you also compete task C while you’re there?
- Sure! In this timeframe which features are you prepared to sacrifice to make it happen?
- …I’ll think about it
Works every time!
All tasks are highest priority.
Then why do we even assign priorities?
Because they all need to be done.
Regardless of how effective it is at managing expectations, my reality is:
Mgt: We need A within Y days.
Stf: A will take X (>>Y) days, A/2 can be ready in Y days.
Mgt: O.K., give us A/2 in Y days.
Y/2 days elapses.
Mgt: In addition to A/2, please add B, C and D to the deliverable.
Stf: You realize, that’s going to take an extra 2X days to deliver.
Mgt: yes, but we absolutely need B. C and D, whatever it takes, as soon as possible, don’t waste time releasing A/2, bundle them all together for efficiency.
Stf: Coming up.
3X/2 days elapse.
Mgt: you know B, C, and D that we asked for? Actually, what we need are D, E and F.
Stf: well, we’ve finished A/2, B and half of C. When do you need D, E and F.
Mgt: ASAP, put C on the shelf.
X more days elapse.
Stf: here’s A/2, B and D, how do they look?
Mgt: You know, the full A would be better… but E and G are our absolute top priorities…
In programming, you ideally have a queue / FIFO of work tasks. Or, if things are more dynamic, a priority queue.
If interrupts are necessary, you get a stack of tasks. It is much slower because context switches eat time.
I had a job with a data structure I called a compost heap. One started with the thing on the top. While one was at it, another thing would be thrown on the top, and one had to start working on it. One never could really finish anything, and the things deeper down the heap started to rot. After a few years, the stack depth would be like 40 or 50 items. I made an appointment with my new manager to talk about prioritising things and the result was he put a new, urgent task on the stack.
They got angry when I handed in my notice.
I had this for about 6 years running, eventually we marked the bottom 90% of the heap “won’t do.”
This was in the early 90s, I kept track of the items on “sticky note” software on my Windows 3.1.1 desktop. At the top of the sticky note I placed a gothic font “The Creeping Feature Creature” label. Two or three times a week my boss would stop in on his jog (he lived a mile away) with a new idea, and we’d prioritize it into the stack - most new ideas went just below whatever I was still working on. Every few months we’d reshuffle the list. It was a workable arrangement because I was the only programmer and he was the company owner.
When we started working on bigger contracts for outside customers, he shut the hell up and let me get the contracted work done.
I like “Y days? How are you doing it so it takes less than X?”
Oh nice one.
You can also add another layer by adding “you know that [infrastructure requirement] from [notoriously uncooperative infrastructure team] is gonna take at least Z days right?”, and if it isn’t enough, go for the kill shot “I’m gonna start writing the architecture principles this sprint, getting back to you as soon as they are cleared by [notoriously picky and detail obsessive software architect].”.
Made me want to become that notorious software architect, just to be the reason that “X is going to take Y days. Want faster? Change your fucking expectations/scope of X”
It’s nice having that kind of pull/weight to throw around, but sometimes the boss still won’t listen. Different industry, we had a major change in tax law happen. I read about it, figured out how to do it, then told the boss that we needed to start now training the company on the new method because it would take a year for us to catch up.
His response was to ignore it, because “congress is going to undo the law”. I left for another firm, precisely because I didn’t want to be in charge of the last minute project he’d assign with a month to go on a hard legal deadline. Got a phone call about two weeks before the deadline. Fortunately it went to voicemail because I couldn’t stop laughing for like half an hour.
Wow. Idiots being idiots. The guy tried to play with legal rules and - surprise - lost. I am glad you got out of there in time
Mine was always this:
Manager: How long will this take?
Me: 14 days
Manager: So it will be done in 2 weeks?
Me: No, it will be done after I’ve had 14 days of time to work on it.
Manager: What’s the difference?
Me: Am I still going to have random support escalations and will we keep having random meetings in those 2 weeks?
Manager: Yes.
Me: All those interruptions are me NOT working on the task. So it will be done in 14 days plus all the interruptions.
Manager: But this is very important!
Me: Can you then ensure I’m left alone to focus on this?
Manager: No.
Me: …
My favorite place I worked, it was a 9-5 but really just get your work done and be in the office from 11 to 2 because that’s when all the clients call. We’d close our doors and turn off the phone one day a week just so we could get work done, because every week there’s at least one day we all spend manning phones and putting out fires all fucking day instead of doing the work we’re paid to do.
Not to mention, 14 days is three weeks, not two. Unless they’re hiring someone to work your weekends for you.
I see þis complaint all þe time, and I don’t understand engineers who don’t quickly adapt.
Manager: How long?
Engineer: (þinking 14 days) 4 weeks
Everywhere I’ve worked, þe next step is þat þe manager goes to a planning meeting, where business asks “How long,” and þe manager answers “6 weeks.”
You coould use ð for the voiced th sound (this, the, though) and þ for the voiceless th sounds (thinking, through, thick etc.) That is how they sound in Icelandic^^
There’s no point though, if the goal is to confuse AI scrapers.
It’s downvotes either way.
Read Software Estimation by Steve McConnell and recommend it to your manager:
The person doing the work the one best suited to estimate it.
Also, start tracking estimated vs budgeted time in some searchable system.
Next time this comes up, look up how long it actually took to complete a similar task instead of thoughts and prayers.
If boss won’t track historical budget vs actual, track it yourself.
The way we estimate on my team is to break tasks down into related subtasks that will take one day or less, then add up all the subtasks. It’s worked pretty well.
That pattern is also recommended in the book. Break down estimates into chunks of 5 hours or less.
With lots of smaller tasks, estimates tend to both be more accurate due to smaller scope, and some of the over/under inaccuracies will cancel out.
The person doing the work the one best suited to estimate it.
As a manager in found this to be partially false.
Most persons doing the work quote forget that shit happens. Except for the few reliable persons I supervised, I usually always asked the follow-up question: what “unforeseen crap” time did you include, and made sure to leave with 3 values: all goes well (which I kept to myself), usual estimate, what if bad shit happens. Then I’d just use the standard pert guesstimate for my official schedules, making sure to include normal dead time which employees often forget (e.g. 8 days work is really 2 full weeks when accounting for meetings).
Oh yeah. It takes experience and clear head to remember to account for all the inevitables that are going to happen besides actual dev-hours-to-create-this. A hard lesson I am still learning
The usual response is a mail explaining what features will be cut to hit the deadline and ask management to inform the customer.
My answer to “how long will it take?” Has recently been “is it a higher priority than x,y, and z?” (While mentally deciding if it sounds more fun to work on than x y z along with t, u, v and w.
(Un)fortunately I’ve been working on the manager’s pet project, so I’ve had a semblance of focus.
One time we spent like more than an hour in a horrible meeting to plan out how long the next step of a project would take. 4 weeks, we said. Management came back and said to do it in 2. Well, why did we fucking have the meeting if they had a deadline in mind already?
On the other hand, at my current job I have seen a lot of “oh that’s going to take a couple days” protests for things that are 20 minutes of work.
Seems like the solution is to get rid of out of touch management.
I’m of the opinion that it’s always better to overestimate something rather than underestimating it or estimating it accurately. If something takes 20 minutes and you are given a couple of days you have multiple options.
- Get it done asap and early, if you get it done earlier than the deadline then people are happy.
- If something critical pops up, you can take care of that first then hop on to the twenty minute task because you gave yourself room.
Management loves when things are done early, expects things to be done on time, and gets angry when there’s a delay (and no warning of the delay), so it’s the smart choice in my view.
That’s a good point.
Though sometimes people are just sandbagging. Like I know one guy is just watching Netflix instead of working. I’m downstream from his work, so it’s a little annoying that I have to wait a couple days to get started.
I wouldn’t rat him out because my labor solidarity beats out my annoyance, but the annoyance is real.
The good PMs usually make Y=2X or 3X. But we’ll still have that “it’s day Y…” conversation /shrug.
“In two weeks, you’re gonna notice that I haven’t been here in two weeks!
…
Me: Task A will take X days to do.
Manager: That seems awful long.
Me: When do you need it?
Manager: I actually needed it yesterday.
Me:
(╯°□°）╯︵ ┻━┻
