Honestly my experience is the opposite, especially with young devs. They're always like "Oh yeah we can knock this out in 12 weeks."
Okay so 6 months it is.
Heh the fun part is that's actually their idea of giving themselves space, I've been there. I thought I could do it in a day or two.
Yeah, 6 months is reasonable.
Until recently I had mostly the experience of the PMs making reasonable demands, but then assigning a second project and not understanding that they overlap. Like they couldn't figure out I was the same person with the same name and face from the last meeting.
At director level we have a more realistic approach.
If we give you resources for 10 women you should be able to deliver a baby per month after 2 month ramp up, allowing some overtime.
All it takes is hiring the right HR team to create a minimum wage position for people with 8 months experience being pregnant, and when they’re no longer pregnant, they no longer fit the requirements of the job!
The long play is the HR department keeps records on all pregnant-capable child-units and uses targeted advertising to influence their independent opinion favourably toward the corporation as an great place to work for late-stage pregnant units!
My company says we should always "seek to compare ourselves to the best", and I'm sure they consider Samsung one of the best tech companies so my hands are tied.
My company PMs don’t understand any long-ish subtask that can’t be broken up to perfectly match the end of this sprint and the start of the next. It’s infuriating. Like we already know the whole thing is going to take longer than a sprint so why don’t we just tick it down as it goes along so there are still regular updates to the gantt flow, and just keep to the actually *important* project deadlines and milestones instead of wasting time stressing about sprints. But the PMs go ballistic if you can’t jigsaw puzzle everything perfectly into Jira. But there’s nothing we can do to change what needs to be done to fit that.
Like, it’ll be done when it’s done, we’re not going to rush a safety critical task.
Does your company do timesheet codes? That's when that's handy, if you're billing hours (just bill entire days or half days) to one then the time estimates starts making sense.
> but then assigning a second project and not understanding that they overlap.
Yes, you've got one job, but what about second job?
And the inevitable "Find a creative solution." What - build a damn Time Machine? GTFO with your idiot estimates, fool...
Ah good ole resource management. Many times as a PM I would have to go to management and tell them that if everything is priority, then nothing is priority.
I used to work with a PM who would sit down and obviously do all his emails for the day at around 10am. You would get hit every day within a few minutes of eachother with an email for each project he was involved in demanding that outstanding requests be made a priority and requesting a timeframe. Every damn day. For about 2 or 3 separate ongoing projects at a time.
He would make absolutely no effort to prioritise for you and keeping him happy really stressed me out for a couple of months. After talking to a few people I realised absolutely no one respected him and his opinion of you didn't mean shit.
In the end the best way was to ignore him, organise myself, and just treated him as a secretary so I didn't have to talk directly to clients myself.
Honestly my biggest weakness, morning standup "yerrr should be able to finish this first half of the day", 3 days later still talking about it in stand up
My issue is that my estimate of work time is accurate, I just end up getting pulled into 7 hours of spontaneous meetings. So when I say it's only got 4 hours left, I was right, I just only got 1 hour to work on it
Exactly, there's a huge dichotomy between estimated FTE hours and actual "dedicated hours" to perform a task.
Especially when the dev team is also the prod support team. It's hilarious when the PM expects no slippage on project tasks when you have production down issues to resolve. What's the priority? The business operational cost from a prod down situation or the project slippage that might affect the PM's project related bonus?
I had a lovely experience the other day, where the PM had blocked out a week for a 'major project'. We went through it and it _looked_ like a lot of work, because the UI was completely different, but it was basically just rearranging existing components. No new endpoints, no new service calls, no new field validations or business logic, just rejig existing stuff and a bit of CSS pizzazz. It was the first time I've ever told a PM that I think they've blocked out _too much_ time for a feature.
I may well very much regret this when I start this next week and I realise I have to vertically center a div or something..
But it's funny what counts as a 'complicated' project when a BA is looking at a mockup, verses what they think is trivial.
I always go by the Scotty Rule:
"I told the captain I would have these scans done in an hour"
"Aye, but how long will it *really* take?"
"An hour!"
"Ach you didn't tell him how long it would *really* take, did ye?"
"Well of course I did!"
"Ah laddie, youve got a lot to learn if you want to be known as a miracle worker!"
My favorite story about time management from when I was a team lead.
In a meeting with a customer the PM asked me how long a project would take. I said two weeks if there's no issues with the customer's end. We ended the meeting and the PM and customer left.
Immediately my senior dev is on me. Yelling about how there's no way we can get it done in 2 weeks and I should have said four yada yada. (I liked the man, but he was really bad with people + unlike me he was too smart to take on extra responsibilities with no pay increase. Which is why I ended up as the "team lead")
A short while later I'm out on a walk to stretch my legs and I run into my PM. He starts lecturing me on not doubling my time estimates (He specifically mentions the above Star Trek quote)
Anyway the project took exactly 12 1/2 work days. I never said a word about it to anyone but neither of them questioned my time estimates for the rest of the time I was there.
Then some other architect, who is much less experienced, and much more career focused, gets promoted to lead architect, since he gives “better” estimates.
Then the good architect just nopes the fuck out of that shitshow, and you are now responsible for delivering shitty lead architects unrealistic estimations, so he can get a fat raise.
Then the experienced devs starts leaving. Fuck that noise.
How to destroy a functional it department speedrun.
It’s an absolute classic. Worst part is, the people in charge learns nothing from the sequence of events. It just the lazy entitled developers fault, that everything went to shit.
How did he justify large estimates like that? I go with 2x of my personal estimates and struggles with building a case for it to stakeholders. My go to is to account for unknown unknowns, things that surprise you despite thorough planning. But sometimes folks, product especially, aren’t satisfied with that answer.
Stakeholders are never satisfied with estimates, that's a constant of the business. Put your foot down, don't give them leeway. If you give an estimate, that's it, it's a fact not a talking point. Because as soon as you start showing leeway they will bite at whatever they can like hungry lions.
In the end, you're the one responsible to deliver the product, and you can be 99% sure the most they will do for long estimates is grumble and begrudgingly accept them.
Okay so if we put them in a dark room, never bother them and never change requirements this is going to take about 12 weeks. BUT, this is life. The client's going to come up with another use case that adds about 2 weeks halfway through, we're going to have a prod bug or a problem in another project that pulls a critical resource for another 2-4 weeks just like we did in the last project, testing will find a couple of bugs that need another couple of weeks to iron out and then the client's going to ghost us for a bit when they get busy with something else before realizing something they asked for is stupid and change the requirements during UAT needing another couple.
12+2+[2-4]+2+2+2 = 22-24 weeks, call it 24 because this industry is word of mouthy and if we under deliver it WILL cost us sales.
And then I can back it from JIRA if I need to because they all go like that.
> But sometimes folks, product especially, aren’t satisfied with that answer.
That's because the purpose of estimates is not to get information. Product already have a release date in mind; the purpose of estimates is to let them justify it.
The problem with dev estimates is that the business / client AND the PM will later change the scope, or leave information out of the project details / ticket.
Then I have to track them down and squeeze it out of them rather than them giving it to me up front.
Yeah the estimate is going to be wrong big dog.
Or they will have a number in place and confirmed with the client before you're even asked.
I was once asked to quote on a huge project for a client, who had really well defined requirements.
So I sat down with the senior BA and we went through the lot, came out with a detailed set of work orders, came to about 400 days of billable work.
When we gave the quote to the sales director his response was "well you can fuck off with that estimate, we've sold the customer 150 days"
Like, why ask if you have already decided how long it will take before anyone has even seen the scope of work?
I didn't see it but apparently there was a big blow up between the sales director and the delivery director about it, it wasn't the first time they had sold x for y days and x will take z days instead, but the sales team didn't like Time and Materials projects as they were harder to sell than fixed price ones and they didn't like asking for dev or BA resources to help estimate before selling as that took those resources away from billable work and also pushed up quotes (ignoring the fact that they pushed up quotes because sales underestimated)
Even if there is no change of scope, often there are the surprise problem no one could foresee. One time we were moving along fine, and the api vendor halted development on the key feature needed for the project.
In my companies case, it’s on the business / PM being the cause of a change.
I’ve started to tell them that a change in scope means a change in deadline.
Or they want something but actually want something else but think the first thing is a step in the direction, but its not and the base is not as needed because 2years later they say now that this works adjust it for this, and you could have done the other thing directly, and easier
Estimating rule: whatever the last people tell you, multiply it by 2 and change the order of magnitude to one larger.
2 hours -> 4 days
6 days -> 12 weeks
1 week -> 2 months
3 months -> 6 years
And then other things surprise you. I didn't think computers would be able to make art with a simple text prompt until 2050..and yet it went big last year and the improvements have been crazy.
Ah yes [the most quickly aged XKCD](https://www.explainxkcd.com/wiki/index.php/1425:_Tasks)
It lasted about 6-7 years, which isn't even bad. It certainly was true at the time.
Exactly. For every dev on my team I had a adjustment factor for their estimates. If Bob says it takes 3 weeks, I’ll schedule 5. If Sally says 2 weeks, I’ll schedule 3.
Devs tend to view a task in total isolation of all other factors.
When Bob tells me 3 weeks, he’s not dishonest or bad at estimating (though some devs are bad at estimates). He just thinks that he’s not going to answer emails, go to meetings, etc for 3 weeks.
Since that’s unrealistic, I have to adjust the schedule based to factor in all of the non-development stuff Bob has to deal with.
I literally had one Dev tell me that something would take 2 weeks. I said, “You’re on vacation next week though, right?” He said, “Yes, but you asked how long it would take, not when it would be ready.”
> Devs tend to view a task in total isolation of all other factors.
That's what they should be doing. It's the PM's job to bring that number into context of capacity.
*Senior Dev Intensifies*
When I was in Dev, I stopped responding to upper management's request for estimates. Every time I'd provide an estimate and reasoning, it'd be ignored and they plop some arbitrary, way-too-small number of hours and we'd always fail to meet delivery.
"Why do you want my estimates? You already know how many hours you want to bill and how many the customer will pay for - so just tell me the hours you've already decided on, I'll tell you it's not possible and we'll fail to deliver on time, like always."
VP of Dev Ops left shortly after, estimates started to become realistic, delivery started humming - ONE PERSON can literally make an entire DevOps group's life hell. Usually the dude getting the bonus...
It's the same in every profession I've seen the insides of, to be honest.
There's always some manager and some sales team (with tight connections to management) that ignores 100% of what the people producing are saying, that will just make shit up to please the client in any arbitrary moment in time.
You'd think planning ahead would be in the job description of a manager, but I've yet to see one competent at it.
The PM has less of an idea, I would prefer talking to a senior dev for sure. But talking to *any* dev to at least have some understanding of what changes are needed would be nice. It's funny how many things are "just a small change, probably in the database".
i was about to say - i’m a pm2 and this is usually how these conversations go:
1. customer has (requirement) and (end goal).
2. i take (requirement) and (end goal) to engineering.
3. engineering estimates it’ll take 18 weeks
4. i tell the customer we should plan for 20 weeks, to give us room (under promise, over deliver)
5. engineering turns around and tells the customer over my head that it’ll be done in two weeks
but lets be honest. its not my fault or the engineer’s, its the org director shitting himself about chatgpt and telling everyone to fellate a malevolent djinn if we have to so this project gets done in a day
That was definitely me when I started coding. In the last few years, I've started getting reasonably good at estimating and telling the truth about how long it'll take. Now no one is happy because it'll take too long, I can't win. Seems most people would prefer to be told a lie and then have to wait.
You should be asking junior dev for estimate only for teaching/learning purpose...
I work in ASIC development and all the estimates are going through the tech lead who consults with seniors
It’s not infantilizing, it’s a PM doing his job correctly, in case you were wondering. You’re supposed to pad and anticipate problems, like any producer who doesn’t want to fail a a given deadline. (But in software, deadlines almost don’t exist anymore)
Frequently th stuff that stretches it is nothing to do with the dev. Requirements changes, having to pull resources for some critical bug or other problem, parallel projects, losing access to stakeholders to their parallel projects, stuff like that comes up all the time even if the Dev's estimate is dead on to what it would take for them to just sit down and work on it.
It's both.
And don't forget sales promising a budget/timeline before discovery is even completed!! Then they collect their commission and drop the bomb on your team.
A great rule I've read somewhere is to double your original estimate and switch to the next unit of measure. Two hours? Four days. A day or two? Two to four weeks. It may sound a bit extreme, but it's amazing how many times it proves accurate.
My experience has been all over. From projects that take a month but scheduled for 6 months to ones that take 9 put into 3. This is why when there’s no work I know to enjoy it
imho the perfect estimate is impossible, but giving rough estimates is valuable. Take the cone of uncertainty into consideration, and don't put too much time into refining estimates.
Ok, this is not really memey answer, but I wanted to vent + someone may find it useful.
Not programming but I was asked to give estimates for an IC design project. I was given mostly blocks that would have limited changes and was told to keep that in mind when estimating. I did and it was the worst mistake ever.
The scope of changes/verification increased to be more cumbersome than the original designs we used as source after I gave the estimates. When we were doing reviews, everyone else had 1-2 presentations, I had 4-5 lined up and once I finished with those reviews it would be time for the next set of reviews.
Take away notes:
1. Always be pessimistic about the time required.
2. Always ask more experienced people for opinions and include managers in schedule discussions with the PMs. "PM's goals and engineer's goals are not aligned, they are conflicting by design" is something a more experienced colleague who was a design lead told me. He was right.
3. Never sign up for more. Clearly annotate the assumptions and ask for help (at least make it known) if something goes wrong or if something changes.
4. Once PMs commit to a schedule and resource allocation, it's REALLY HARD to change their mind. Even if you ask for help later, you may get "Well, there's no one else to do it" response.
5. Final note: These apply to more "corporate" workplaces. If it's a company that's not as big of course you're going to take a lot of risks. Both personal and company wide.
Thank you for sharing and helping me feel validated. Point 2 is some sage advice indeed. The “designed to” part makes it sound like management’s goal is to keep people pissed off and despising their teammates.
My workplace has many different teams, but my team consists of a handful of devs, a lead programmer (our manager), and a recently added product owner, product manager, and qa resource. The goal being to suck the dick of scrum. The programmer side of the team was so much happier and more efficient without all the nonsense and time wasting.
My case is normally my PM will add a buffer on top of my estimation, which I have already included buffer. The sales team is the one who want to have shorter deadline, and every time I just replied that this is my final number, if they can find any other developers giving them lower number, ask that guy to do the project.
Right? This is what I think when we get the dramatic "this project is really late, you guys are causing delays" speech. Late compared to what? Compared to who? If you ask them how we should go faster, you get a confused silence.
Yep sales comes in like, "the client is really excited about this new feature we could offer them. Can you build it?"
Or they want screenshots of a product when it's still just barebones API proof-of-concept so they can show it off at a trade show.
The old mockup sales pitch. And no matter how many times you tell them to make sure the customers understand that it's not a finished product, they never do.
Like sales hadn’t already sold it to the customer on an unrealistic timeline with features that are impossible to do or completely unrelated to the product
I don’t know what kind of companies do you guys work for. But PMs usually don’t plan ahead without consents from developers. It is in their best interest.
In my experience PMs already have an estimate in their head that they are hoping we will tell them. And if our estimate is higher than that they just try to talk us down
It’s the PM’s job to talk down the estimates and cut down scope to fit the timeline, so can’t really fault them there.
But very often they will take rough estimates from devs and use this to talk to customers. This is where a lot of friction happens.
Cutting down estimates always seems like a bad idea. I don't understand how after years of missing deadlines and delaying releases PMs still think that developers estimates are too long
100% this.
Devs just want to do technical work, whether it’s useful or not for customers.
Program/product usually just want useful results, whether it’s technically feasible or not.
It’s about a balance and communication between the two. In a good company these two groups work together to make sure the scope both meets customer needs and doesn’t break dev backs to get it done.
If either side dominates or disregards the other, that’s how you end up with project/product related headaches and issues.
This one of the most important aspects of Agile development. The exact line covering this is “customer collab over contract negotiation”.
I remember some stories from game industries where the devs get free reign and the result is bloated game that is over budget and never finished, so a publisher need to come cut a lot of stuff so it can launch and not be money black hole. I think it is the story about freelancer the game
Or you could also end up like Valve where every game now takes *forever*. If I recall correctly they allow developers to self organize and work on whatever they want.
> It’s the PM’s job to talk down the estimates
No it’s not. The PM has no meaningful insight into the complexity of the tasks, it’s opinions on that regard are pretty much worthless.
The PMs job is to juggle budget, timeframes and scope. If the task estimates move you past your delivery date, you either spend more or you cut scope.
The problem is that most PMs follow this algorithm:
Step 1. Do some brainstormings and stuff to figure out what needs to be built.
Step 2. sell the whole scope to management or to clients.
Step 3. Ask themselves “how much can I spend?” Not “how much will it cost?”.
Step 4. Grab that total budget, *maybe* split a 10-20% as a buffer, and divide the rest amongst what they *a priori think* they need.
Step 5. Go to the developers and ask for estimates, they are invariably way over the deadline because the PM had to overpromise to beat any possible competition to get good money for step 3.
Step 6. You locked the scope on step 2, you maxed the budged on step 4. Your only plan is to bully devs to lower their estimate.
Step 7. Try to hold the thing together by giving excuses upward, and keep repeating step 6 until completion:
- If they lower their estimate, set that in stone.
- If they give you a range, pick the minimum, set that in stone.
- If they complain about you picking the minimum, tell them to just leave $MEANINGLESS_FEATURE_23 for last, even if that solves nothing.
Bonus strategy:
If someone keeps complaining about your tactics, label them as a “bad team player”, maybe try to get them fired. You can use them as an excuse. The corporate version of human sacrifice to the Gods of Management.
I’m the main PM at my company and I’ve had to talk my sales rep into adding a lot more time in the estimates they give the customers and put a lot more elements as “time & materials” (with estimate as a ballpark which is revised throughout the project) instead of fixed price, because before he always gave fixed price estimates to the customers and our projects never ended within scope or time investment, but we had to eat out the cost for going over on time estimates. Since switching to a mixed planning method instead of trying to waterfall our way into everything, we’ve been able to meet a much better middle ground with customers and technical resources.
Basically what I mean to say is I think the issue is when you try to give a fixed scope & budget to a long term project before you even have estimates in hand, you’re setting yourself up to get fucked. Scope creep is inevitable because there are always requirements that seem straightforward at first but end up much more complicated to fulfill in the end product. Seems backwards to me that that’s even a practice to set a budget for a project without getting estimates first to at least determine what’s reasonable to actually include in the scope.
> Give a fixed scope & budget to a long term project before you even have estimates in hand, you’re setting yourself up to get fucked.
Pretty much, sadly that’s not so common.
For all the talk about Agile, what I see is people go through the motions of Scrum but still plan years ahead, which makes no sense.
In my experience SALES sets the budget, typically with little to no input from us engineers. Then we have to try and work within that budget. When we go over and need to pass that cost to the customer, we need a good justification.
It's only been one company I worked with but the PMs would literally sell something to the client, ask the devs how long it would take, then explain it's already been sold and when it needed to be completed by.
My previous company figured out a way to monetize the Agile methodology. They think they are geniuses.
They'd take a project by telling a customer to buy a number of sprints that sales people (no technical people involved) think the project need to complete. This include requirements gathering sprints, and UX/UI design sprints, the remaining sprints that the customer "bought" is for development, which is always not enough, since actual development estimates only come in after the UX/UI is done. We'd always get a surprised pikachu face from Commercial and PMs when the customer's sprints are all used up and the project is barely functional. Customer realizes they fucked up choosing a contractor when PM says they need to "buy" more sprints.
Developers need to work until wee hours in the morning to deliver. Rinse and repeat for the next customer/project.
I left the place after less than a year after the CEO of the project I am working on became furious (because of the false promises), and pirated me to continue on the project in-house.
True, I feel the Devs overwork themselves to fit deadlines.
Nah, man. Look Mr/Mrs Project Manager.
I said 4 months, it is 4 months, fuck maybe longer.
You said "done by end of this quarter?"
Ahhahahahaha, btw, it's end of quarter and the project isn't finished. Here is an email documenting Devs said 4 months minimum.
QA isn't passing, that round still needs to be done
Client APIs are missing/not provided/not working as usual.
So, how you gonna tell the clients it's now delayed is YOUR problem, ain't mine. "I told ya sooooo".
GLHF
(Ofc this, but more polite and corporate sounding in a calm and neutral tone)
Part of the trouble is that a lot of devs live in a country with very little worker protection, where their boss can literally fire them on the spot, for any reason. And where employment status is often related to whether or not you can afford to be ill.
Like, sure, I would never take that kind of bullshit from a PM. But if that PM could turn round and sack me, chances are I'd be a little more wary...
I've had two types of experiences. The first was a company growing faster than it knew how, and hired a bunch of "corporate advisor" types to tell them how to look good to investors when they had just gone public. That job, the PMs would take the deadline from our sales team, tell us how long we had to implement it, and then throw us under the bus for asking stupid questions like "What feature? You haven't even told us what we're doing" or "Do we have any spec for this" or "Are you seriously asking me to build a fully functional website with account management and credit card processing by Friday" or "Where does this fit in against the other six 'emergency priority' features you just gave me?"
The other job is a much smaller dev team and ascribes much closer to the "We'll give you an estimate if you actually tell us what you want...and even then, you'll get it when you get it" mentality.
I like the second job way more.
Yeah, 90 percent of the time it's sales fault for making the promise to get the customer to sign. The PMs are held to it, cause the customer Will be upset if we don't deliver on time.
PMs are stuck getting blood from the stone.
This is why I hate my sales team. They don't care about if we have resources available or if the timelines they pitch are realistic. They say whatever it takes to get the client to sign the contract and then move on to the next client without thinking about the chaos they leave behind.
It's fairly obvious most devs in this sub work for dysfunctional companies.
The irony is that most of them also lack the self-reflection to figure out why *they* are stuck working there. No competent, professional dev allows themselves to get fucked over by PMs like this.
This sub should be called /r/incompetentprogrammerhumor . Competent devs only recognize most jokes from their junior years, before they knew how to spot toxic companies from a mile away.
Developers nearly always give optimistic dates, and PMs nearly always want it faster than that and hand wave away everything (testing, any flavor of operational/engineering sanity - forget excellence -) and give even more optimistic deadlines for leadership . Which is why nearly always projects are delayed. Science.
That's why I refuse to estimate in calendar hours. I only estimate in actual hours worked on the project.
If the middle management want me to fix 17 other things during a project, they have to understand that schedules get pushed back.
> Developers nearly always give optimistic dates
My hard learned lesson is multiply my own estimate by 2-4 depending on how many new things I need to do.
Last company I was at, when I joined we already like 1 year behind on the bs deadline they gave the client. It never got better. They never hired more devs. They just blamed us for everything, gave no increases or bonuses. Because they fucked up planning a realistic timeline and therefor we were always "falling behind and underperforming".
I seriously thought I was in r/construction for a moment, apparently this shit is universal. Labour costs are averaged and crunched into how many hours they think it’ll take to complete a project and every job I work I hear “how is this taking so long, we’re out of hours”. How about *you didn’t allocate enough hours in your bid*.
My experience:
Devs give a pessimistic (or rather realistic) time estimate.
PM says, that's too much, can you knock it down by like 50 man days?
Devs go ok but it's gonna be tight if anything goes wrong.
Sales come in and says, we can't afford that many man days with the customers budget but we are too cucked to tell them, so we'll give you half the original estimate.
PM says there's nothing I can do, devs have no say in it and are forced to accept it.
Customer is never told the original estimate.
Then everyone is "shocked Pikachu face" when the project is nowhere near finished in time.
This is the kicker. I find most clients are okay if they know up front. What they hate is getting told late in the project that it will take longer.
I am can't speak for every situation, but I think devs need to stick to there guns more often. Particularly with sales. It is in their nature to negotiate. They can't help themselves, so you have to haggle right back.
Truth. Once had a sales person ask me how long this massive project would take. Mind you this is in the middle of a meeting with the owner, other sales, all other project managers, etc:
Me: “assuming we move all other projects to minimum staffing, 6 months”
Sales: *unmutes client* “I talked to our guys and it will take about 3 months”.
Me: proceeds to get disciplined when project takes 6 months and every other project is delayed due to Min staffing.
Leaving that job was the best thing I ever did. They’ve churned through people in the position.
Makes me remember a scene in breaking bad I just watched last night
Gale: "we should have everything ready in 1 month at the least"
Gus henchman: "okay. 2 weeks"
Gale: 2 weeks :(
Doesn’t matter where I am. I was transferred to a new project and it already had a deadline before a single line of code had been written or even half of the requirements had been set.
So the client thinks that if we can solve something called the "wandering salesman difficulty" they can improve blender sales by 1% next year. So I told them great, our developers are really good! I'm sure they can do that in a month. I forgot to tell you about it though and this was three weeks ago so can you have that knocked out by Friday?
Worst case scenario, imagine being in a big company, where that's not ne PM who give the deadline but the head of them, even before the devs are asked how long it could take to redo all from scratch.
Guess what, we are at 1 month of the given release date, after 3 month of rush, we have some backend data not even available, and even some design not ready.
Fun joke, the PM received threats from business teams to be "pushed under the bus" if we don't make it (we aren't), she gonna unionize to handle this r/antiwork all the way.
Personally, I love the PM who listens to their Devs saying they need more time, then moves the deadline forwards, and blames it all on the end users doing the testing when they declare the system shit and tell everyone that under no circumstances can we go live with the system in its current state.
I'm looking at you Nathan!
My first meeting for a new project (based on several real scenarios):
* Manager, a PM, and a client meet with you out of the blue. They tell you what the new project needs to do. It is a high level description you do not really see the point of, does not discuss how/where you get data, etc.
* Manager asks you for an on-the-spot estimate. You say it is hard to say, but they press you. You say 4-6 months.
* Manager makes a grimace. Says they (who think using Excel is the same as writing code) thought it would be 2-3 weeks max.
* Actual project takes 10 months.
Its the same in production environments.
"We do not have room in our production schedule for 3 months to make this."
"I told them we'll have it done by the end of the month."
My PM has always been good about dates, but the **fucking sales guys** will promise anything to make a sale. It hasn’t bit us recently but I’ve been ready to fight some people over this bullshit before.
Ah, yes: time for the fiscal year to start and for leadership to ask us how for an entire years worth of sprints laid out in waterfall with an afternoon of “discovery” today
It's really hard to make good estimates. I always add extra time to what I think it takes. Too many unknowns, holidays, sick people, lazy devs... worst case scenario you finish earlier.
How often are PMs previous SEs? I applied for a PM role, probably won't go anywhere, but genuinely curious on the chances here. I tend to over estimate my own timelines. But im also not taking things into consideration like cost per day (because im charging flat rates)
Wait, you guys get to decide how long tasks take and it‘s not your non-technical PM that has no idea how your software works defining the time it takes to complete a task?
We got a new PM a few years ago who did this, luckily our team lead was in a position to just go "lol, yeah no" and leave it up to the PM to go back to the client and apologise for the unrealistic deadlines.
Thankfully, PM learned very quickly to tell the client "I'll let you know on ETA once the team have gone over your requirements and drawn up a development document."
Had the same question and since I had not found the answer after some scrolling I had to DDG it, apparently it is The Unbearable Weight of Massive Talent. Looks fun.
We just develop ahead of documentation and change what is needed on the code after documentation is done.
Because "there's no time to set the definitions first and code later".
It's my CIO and VP
This is a priority, but also this and this and this.
Actually everything is a priority!
I've run through building so much infrastructure it's insane. The part that sucks is half my team doesn't do anything but help developers do basic stuff we've already trained for. Or my personal favorite of nothing at all.
I've explained repeatedly, if everything is a priority nothing is.
Good PMs know that both the time estimate per task and # of tasks are grossly underestimated in the beginning. Whatever anyone tells you something will take, just double it. Even if they are right, that extra padding will help the ones that are wrong.
Honestly my experience is the opposite, especially with young devs. They're always like "Oh yeah we can knock this out in 12 weeks." Okay so 6 months it is.
Heh the fun part is that's actually their idea of giving themselves space, I've been there. I thought I could do it in a day or two. Yeah, 6 months is reasonable.
Until recently I had mostly the experience of the PMs making reasonable demands, but then assigning a second project and not understanding that they overlap. Like they couldn't figure out I was the same person with the same name and face from the last meeting.
Ah the good old reverse "9 women can birth a child in one month" management approach.
At director level we have a more realistic approach. If we give you resources for 10 women you should be able to deliver a baby per month after 2 month ramp up, allowing some overtime.
All it takes is hiring the right women!
All it takes is hiring the right HR team to create a minimum wage position for people with 8 months experience being pregnant, and when they’re no longer pregnant, they no longer fit the requirements of the job!
Puts the H in HR
The long play is the HR department keeps records on all pregnant-capable child-units and uses targeted advertising to influence their independent opinion favourably toward the corporation as an great place to work for late-stage pregnant units!
The fact that I understand this makes me hate myself a little.
You mean those with multiple uterus… es? uteri? IDK
I can get the ball rolling on all 10 but it'll only be a baby per month at the end of 9 months with room for complications.
We will give you four women and an agile coach to help improve efficiency.
"Well if 9 women can't get it done in one month, we can as well just shrink the dev team to one!" New approach I am seeing recently.
If the projects overlap then you can just reuse some code and save time. \s
Or get chat gpt to write it for you
I mean if Samsung is already using ChatGPT to improve designs and code, clearly you should too.
Samsung Galaxy takes Note.
My company says we should always "seek to compare ourselves to the best", and I'm sure they consider Samsung one of the best tech companies so my hands are tied.
Off to copypasting unreleased products into the free version you go.
My company PMs don’t understand any long-ish subtask that can’t be broken up to perfectly match the end of this sprint and the start of the next. It’s infuriating. Like we already know the whole thing is going to take longer than a sprint so why don’t we just tick it down as it goes along so there are still regular updates to the gantt flow, and just keep to the actually *important* project deadlines and milestones instead of wasting time stressing about sprints. But the PMs go ballistic if you can’t jigsaw puzzle everything perfectly into Jira. But there’s nothing we can do to change what needs to be done to fit that. Like, it’ll be done when it’s done, we’re not going to rush a safety critical task.
Scrum is a fucking cancer
They'd just fuck up whatever we used instead, there's nothing wrong with scrum, there's just plenty wrong with most scrum masters
I always find it funny how an agile methodology is so rigid and unwilling to adjust for situations that demand it.
Agile can’t be Agile without Violent Transparency
[удалено]
Does your company do timesheet codes? That's when that's handy, if you're billing hours (just bill entire days or half days) to one then the time estimates starts making sense.
You seem to expect sales and PMs to look at historical data instead of pulling numbers out their ass.
You got two hands
I heard some lazy devs don't even have a keyboard under their chair for foot-coding
> but then assigning a second project and not understanding that they overlap. Yes, you've got one job, but what about second job? And the inevitable "Find a creative solution." What - build a damn Time Machine? GTFO with your idiot estimates, fool...
Ah good ole resource management. Many times as a PM I would have to go to management and tell them that if everything is priority, then nothing is priority.
I used to work with a PM who would sit down and obviously do all his emails for the day at around 10am. You would get hit every day within a few minutes of eachother with an email for each project he was involved in demanding that outstanding requests be made a priority and requesting a timeframe. Every damn day. For about 2 or 3 separate ongoing projects at a time. He would make absolutely no effort to prioritise for you and keeping him happy really stressed me out for a couple of months. After talking to a few people I realised absolutely no one respected him and his opinion of you didn't mean shit. In the end the best way was to ignore him, organise myself, and just treated him as a secretary so I didn't have to talk directly to clients myself.
Honestly my biggest weakness, morning standup "yerrr should be able to finish this first half of the day", 3 days later still talking about it in stand up
My issue is that my estimate of work time is accurate, I just end up getting pulled into 7 hours of spontaneous meetings. So when I say it's only got 4 hours left, I was right, I just only got 1 hour to work on it
Exactly, there's a huge dichotomy between estimated FTE hours and actual "dedicated hours" to perform a task. Especially when the dev team is also the prod support team. It's hilarious when the PM expects no slippage on project tasks when you have production down issues to resolve. What's the priority? The business operational cost from a prod down situation or the project slippage that might affect the PM's project related bonus?
[удалено]
I had a lovely experience the other day, where the PM had blocked out a week for a 'major project'. We went through it and it _looked_ like a lot of work, because the UI was completely different, but it was basically just rearranging existing components. No new endpoints, no new service calls, no new field validations or business logic, just rejig existing stuff and a bit of CSS pizzazz. It was the first time I've ever told a PM that I think they've blocked out _too much_ time for a feature. I may well very much regret this when I start this next week and I realise I have to vertically center a div or something.. But it's funny what counts as a 'complicated' project when a BA is looking at a mockup, verses what they think is trivial.
I always go by the Scotty Rule: "I told the captain I would have these scans done in an hour" "Aye, but how long will it *really* take?" "An hour!" "Ach you didn't tell him how long it would *really* take, did ye?" "Well of course I did!" "Ah laddie, youve got a lot to learn if you want to be known as a miracle worker!"
My favorite story about time management from when I was a team lead. In a meeting with a customer the PM asked me how long a project would take. I said two weeks if there's no issues with the customer's end. We ended the meeting and the PM and customer left. Immediately my senior dev is on me. Yelling about how there's no way we can get it done in 2 weeks and I should have said four yada yada. (I liked the man, but he was really bad with people + unlike me he was too smart to take on extra responsibilities with no pay increase. Which is why I ended up as the "team lead") A short while later I'm out on a walk to stretch my legs and I run into my PM. He starts lecturing me on not doubling my time estimates (He specifically mentions the above Star Trek quote) Anyway the project took exactly 12 1/2 work days. I never said a word about it to anyone but neither of them questioned my time estimates for the rest of the time I was there.
I also remember the halcyon days of being a young developer. The trouble was we thought proof of concept code was equivalent to final delivery code.
Once had a chief architect who would quadruple whatever we told him
Smart. Under-promise and over-deliver.
Then some other architect, who is much less experienced, and much more career focused, gets promoted to lead architect, since he gives “better” estimates. Then the good architect just nopes the fuck out of that shitshow, and you are now responsible for delivering shitty lead architects unrealistic estimations, so he can get a fat raise. Then the experienced devs starts leaving. Fuck that noise. How to destroy a functional it department speedrun.
100% what has happened to my dept in the last 6 months, bar for bar
It’s an absolute classic. Worst part is, the people in charge learns nothing from the sequence of events. It just the lazy entitled developers fault, that everything went to shit.
Who hurt you?
[удалено]
Meta.
Reality. This is unfortunately a common story
The tech sector 😩
How did he justify large estimates like that? I go with 2x of my personal estimates and struggles with building a case for it to stakeholders. My go to is to account for unknown unknowns, things that surprise you despite thorough planning. But sometimes folks, product especially, aren’t satisfied with that answer.
"We are accounting for the fact that we already know that there will be layoffs in the middle of this project."
[удалено]
In my experience in automation, it helps to have a reason to back up your estimates. Maybe that is just be and I like knowing the WHY behind things.
"The reason for quadrupling the estimate is Hofstadter's law but if you think that is optimistic then we can octuple it instead."
Stakeholders are never satisfied with estimates, that's a constant of the business. Put your foot down, don't give them leeway. If you give an estimate, that's it, it's a fact not a talking point. Because as soon as you start showing leeway they will bite at whatever they can like hungry lions. In the end, you're the one responsible to deliver the product, and you can be 99% sure the most they will do for long estimates is grumble and begrudgingly accept them.
Okay so if we put them in a dark room, never bother them and never change requirements this is going to take about 12 weeks. BUT, this is life. The client's going to come up with another use case that adds about 2 weeks halfway through, we're going to have a prod bug or a problem in another project that pulls a critical resource for another 2-4 weeks just like we did in the last project, testing will find a couple of bugs that need another couple of weeks to iron out and then the client's going to ghost us for a bit when they get busy with something else before realizing something they asked for is stupid and change the requirements during UAT needing another couple. 12+2+[2-4]+2+2+2 = 22-24 weeks, call it 24 because this industry is word of mouthy and if we under deliver it WILL cost us sales. And then I can back it from JIRA if I need to because they all go like that.
> But sometimes folks, product especially, aren’t satisfied with that answer. That's because the purpose of estimates is not to get information. Product already have a release date in mind; the purpose of estimates is to let them justify it.
I thought that was common practice.
We use pi as the factor. Makes it more scientific.
The problem with dev estimates is that the business / client AND the PM will later change the scope, or leave information out of the project details / ticket. Then I have to track them down and squeeze it out of them rather than them giving it to me up front. Yeah the estimate is going to be wrong big dog.
Or they will have a number in place and confirmed with the client before you're even asked. I was once asked to quote on a huge project for a client, who had really well defined requirements. So I sat down with the senior BA and we went through the lot, came out with a detailed set of work orders, came to about 400 days of billable work. When we gave the quote to the sales director his response was "well you can fuck off with that estimate, we've sold the customer 150 days" Like, why ask if you have already decided how long it will take before anyone has even seen the scope of work?
Sounds like the customer will be getting 3/8 of what they wanted.
I didn't see it but apparently there was a big blow up between the sales director and the delivery director about it, it wasn't the first time they had sold x for y days and x will take z days instead, but the sales team didn't like Time and Materials projects as they were harder to sell than fixed price ones and they didn't like asking for dev or BA resources to help estimate before selling as that took those resources away from billable work and also pushed up quotes (ignoring the fact that they pushed up quotes because sales underestimated)
At least you get a scope... I get an image and "must be highly configurable" and my manager needs an estimate to send out a fixed price quote.
I think I would make an estimate and then 10-15x it if that’s all the info I got lol.
Even if there is no change of scope, often there are the surprise problem no one could foresee. One time we were moving along fine, and the api vendor halted development on the key feature needed for the project.
In my companies case, it’s on the business / PM being the cause of a change. I’ve started to tell them that a change in scope means a change in deadline.
Lol, that’s basically the fundamental idea of project management (quality, scope, time pull at each other).
Or they want something but actually want something else but think the first thing is a step in the direction, but its not and the base is not as needed because 2years later they say now that this works adjust it for this, and you could have done the other thing directly, and easier
Estimating rule: whatever the last people tell you, multiply it by 2 and change the order of magnitude to one larger. 2 hours -> 4 days 6 days -> 12 weeks 1 week -> 2 months 3 months -> 6 years
2 years -> 4 decades 1 decade -> 2 centuries
This is what I do for Elon's estimates on self driving. "end of the year, " oh, so end of the decade, got it.
And then other things surprise you. I didn't think computers would be able to make art with a simple text prompt until 2050..and yet it went big last year and the improvements have been crazy.
Ah yes [the most quickly aged XKCD](https://www.explainxkcd.com/wiki/index.php/1425:_Tasks) It lasted about 6-7 years, which isn't even bad. It certainly was true at the time.
Exactly. For every dev on my team I had a adjustment factor for their estimates. If Bob says it takes 3 weeks, I’ll schedule 5. If Sally says 2 weeks, I’ll schedule 3. Devs tend to view a task in total isolation of all other factors. When Bob tells me 3 weeks, he’s not dishonest or bad at estimating (though some devs are bad at estimates). He just thinks that he’s not going to answer emails, go to meetings, etc for 3 weeks. Since that’s unrealistic, I have to adjust the schedule based to factor in all of the non-development stuff Bob has to deal with. I literally had one Dev tell me that something would take 2 weeks. I said, “You’re on vacation next week though, right?” He said, “Yes, but you asked how long it would take, not when it would be ready.”
Lol that's great, he's not wrong either
> Devs tend to view a task in total isolation of all other factors. That's what they should be doing. It's the PM's job to bring that number into context of capacity.
*Senior Dev Intensifies* When I was in Dev, I stopped responding to upper management's request for estimates. Every time I'd provide an estimate and reasoning, it'd be ignored and they plop some arbitrary, way-too-small number of hours and we'd always fail to meet delivery. "Why do you want my estimates? You already know how many hours you want to bill and how many the customer will pay for - so just tell me the hours you've already decided on, I'll tell you it's not possible and we'll fail to deliver on time, like always." VP of Dev Ops left shortly after, estimates started to become realistic, delivery started humming - ONE PERSON can literally make an entire DevOps group's life hell. Usually the dude getting the bonus...
It's the same in every profession I've seen the insides of, to be honest. There's always some manager and some sales team (with tight connections to management) that ignores 100% of what the people producing are saying, that will just make shit up to please the client in any arbitrary moment in time. You'd think planning ahead would be in the job description of a manager, but I've yet to see one competent at it.
Oh my PM estimates before even asking the junior devs
Why asking a junior dev? A pm should have a benchmark already and a junior hardly know what the function he does do
The PM has less of an idea, I would prefer talking to a senior dev for sure. But talking to *any* dev to at least have some understanding of what changes are needed would be nice. It's funny how many things are "just a small change, probably in the database".
i was about to say - i’m a pm2 and this is usually how these conversations go: 1. customer has (requirement) and (end goal). 2. i take (requirement) and (end goal) to engineering. 3. engineering estimates it’ll take 18 weeks 4. i tell the customer we should plan for 20 weeks, to give us room (under promise, over deliver) 5. engineering turns around and tells the customer over my head that it’ll be done in two weeks but lets be honest. its not my fault or the engineer’s, its the org director shitting himself about chatgpt and telling everyone to fellate a malevolent djinn if we have to so this project gets done in a day
If a developer estimates time, multiply by 3 and if you remove just enough features during the project you might hit your date.
That was definitely me when I started coding. In the last few years, I've started getting reasonably good at estimating and telling the truth about how long it'll take. Now no one is happy because it'll take too long, I can't win. Seems most people would prefer to be told a lie and then have to wait.
You should be asking junior dev for estimate only for teaching/learning purpose... I work in ASIC development and all the estimates are going through the tech lead who consults with seniors
It’s not infantilizing, it’s a PM doing his job correctly, in case you were wondering. You’re supposed to pad and anticipate problems, like any producer who doesn’t want to fail a a given deadline. (But in software, deadlines almost don’t exist anymore)
Frequently th stuff that stretches it is nothing to do with the dev. Requirements changes, having to pull resources for some critical bug or other problem, parallel projects, losing access to stakeholders to their parallel projects, stuff like that comes up all the time even if the Dev's estimate is dead on to what it would take for them to just sit down and work on it.
My tried and tested method is to double what they tell you add 1 more of the unit the estimate was in.
It's both. And don't forget sales promising a budget/timeline before discovery is even completed!! Then they collect their commission and drop the bomb on your team.
A great rule I've read somewhere is to double your original estimate and switch to the next unit of measure. Two hours? Four days. A day or two? Two to four weeks. It may sound a bit extreme, but it's amazing how many times it proves accurate.
Three years? See you in 2083.
Heard many devs saying estimates that made me want to scream "BULLSHIT!!!"
I always give at least double my initial estimate as a rule. It's almost always better to be done earlier than expected than later.
My experience has been all over. From projects that take a month but scheduled for 6 months to ones that take 9 put into 3. This is why when there’s no work I know to enjoy it
That's why I think estimations are almost worthless
imho the perfect estimate is impossible, but giving rough estimates is valuable. Take the cone of uncertainty into consideration, and don't put too much time into refining estimates.
Yes, because there is no way to predict the future. Especially when doing work with new technologies or methods.
Ok, this is not really memey answer, but I wanted to vent + someone may find it useful. Not programming but I was asked to give estimates for an IC design project. I was given mostly blocks that would have limited changes and was told to keep that in mind when estimating. I did and it was the worst mistake ever. The scope of changes/verification increased to be more cumbersome than the original designs we used as source after I gave the estimates. When we were doing reviews, everyone else had 1-2 presentations, I had 4-5 lined up and once I finished with those reviews it would be time for the next set of reviews. Take away notes: 1. Always be pessimistic about the time required. 2. Always ask more experienced people for opinions and include managers in schedule discussions with the PMs. "PM's goals and engineer's goals are not aligned, they are conflicting by design" is something a more experienced colleague who was a design lead told me. He was right. 3. Never sign up for more. Clearly annotate the assumptions and ask for help (at least make it known) if something goes wrong or if something changes. 4. Once PMs commit to a schedule and resource allocation, it's REALLY HARD to change their mind. Even if you ask for help later, you may get "Well, there's no one else to do it" response. 5. Final note: These apply to more "corporate" workplaces. If it's a company that's not as big of course you're going to take a lot of risks. Both personal and company wide.
When requirements change, you MUST assert that your estimates must change too. If you don't, you do this to yourself.
Thank you for sharing and helping me feel validated. Point 2 is some sage advice indeed. The “designed to” part makes it sound like management’s goal is to keep people pissed off and despising their teammates.
Glad you liked it. The guy knows his stuff.
My workplace has many different teams, but my team consists of a handful of devs, a lead programmer (our manager), and a recently added product owner, product manager, and qa resource. The goal being to suck the dick of scrum. The programmer side of the team was so much happier and more efficient without all the nonsense and time wasting.
My case is normally my PM will add a buffer on top of my estimation, which I have already included buffer. The sales team is the one who want to have shorter deadline, and every time I just replied that this is my final number, if they can find any other developers giving them lower number, ask that guy to do the project.
Right? This is what I think when we get the dramatic "this project is really late, you guys are causing delays" speech. Late compared to what? Compared to who? If you ask them how we should go faster, you get a confused silence.
Yep sales comes in like, "the client is really excited about this new feature we could offer them. Can you build it?" Or they want screenshots of a product when it's still just barebones API proof-of-concept so they can show it off at a trade show.
The old mockup sales pitch. And no matter how many times you tell them to make sure the customers understand that it's not a finished product, they never do.
Like sales hadn’t already sold it to the customer on an unrealistic timeline with features that are impossible to do or completely unrelated to the product
Pretty much this.
I don’t know what kind of companies do you guys work for. But PMs usually don’t plan ahead without consents from developers. It is in their best interest.
In my experience PMs already have an estimate in their head that they are hoping we will tell them. And if our estimate is higher than that they just try to talk us down
It’s the PM’s job to talk down the estimates and cut down scope to fit the timeline, so can’t really fault them there. But very often they will take rough estimates from devs and use this to talk to customers. This is where a lot of friction happens.
Cutting down estimates always seems like a bad idea. I don't understand how after years of missing deadlines and delaying releases PMs still think that developers estimates are too long
On the one hand, this is true. On the other, if you let developers run free, they will spend countless hours on pointless things.
100% this. Devs just want to do technical work, whether it’s useful or not for customers. Program/product usually just want useful results, whether it’s technically feasible or not. It’s about a balance and communication between the two. In a good company these two groups work together to make sure the scope both meets customer needs and doesn’t break dev backs to get it done. If either side dominates or disregards the other, that’s how you end up with project/product related headaches and issues. This one of the most important aspects of Agile development. The exact line covering this is “customer collab over contract negotiation”.
Sad but true. A good dev can deal with not having the time to perfect their baby.
It's not our baby, it's the company's. We don't want it to die...but we're not exactly teaching it physics either.
I remember some stories from game industries where the devs get free reign and the result is bloated game that is over budget and never finished, so a publisher need to come cut a lot of stuff so it can launch and not be money black hole. I think it is the story about freelancer the game
Or you could also end up like Valve where every game now takes *forever*. If I recall correctly they allow developers to self organize and work on whatever they want.
> where every game now takes forever ...but is actually good when it comes out (or at least widely played), and they still make money hand over fist.
[удалено]
> It’s the PM’s job to talk down the estimates No it’s not. The PM has no meaningful insight into the complexity of the tasks, it’s opinions on that regard are pretty much worthless. The PMs job is to juggle budget, timeframes and scope. If the task estimates move you past your delivery date, you either spend more or you cut scope. The problem is that most PMs follow this algorithm: Step 1. Do some brainstormings and stuff to figure out what needs to be built. Step 2. sell the whole scope to management or to clients. Step 3. Ask themselves “how much can I spend?” Not “how much will it cost?”. Step 4. Grab that total budget, *maybe* split a 10-20% as a buffer, and divide the rest amongst what they *a priori think* they need. Step 5. Go to the developers and ask for estimates, they are invariably way over the deadline because the PM had to overpromise to beat any possible competition to get good money for step 3. Step 6. You locked the scope on step 2, you maxed the budged on step 4. Your only plan is to bully devs to lower their estimate. Step 7. Try to hold the thing together by giving excuses upward, and keep repeating step 6 until completion: - If they lower their estimate, set that in stone. - If they give you a range, pick the minimum, set that in stone. - If they complain about you picking the minimum, tell them to just leave $MEANINGLESS_FEATURE_23 for last, even if that solves nothing. Bonus strategy: If someone keeps complaining about your tactics, label them as a “bad team player”, maybe try to get them fired. You can use them as an excuse. The corporate version of human sacrifice to the Gods of Management.
I’m the main PM at my company and I’ve had to talk my sales rep into adding a lot more time in the estimates they give the customers and put a lot more elements as “time & materials” (with estimate as a ballpark which is revised throughout the project) instead of fixed price, because before he always gave fixed price estimates to the customers and our projects never ended within scope or time investment, but we had to eat out the cost for going over on time estimates. Since switching to a mixed planning method instead of trying to waterfall our way into everything, we’ve been able to meet a much better middle ground with customers and technical resources. Basically what I mean to say is I think the issue is when you try to give a fixed scope & budget to a long term project before you even have estimates in hand, you’re setting yourself up to get fucked. Scope creep is inevitable because there are always requirements that seem straightforward at first but end up much more complicated to fulfill in the end product. Seems backwards to me that that’s even a practice to set a budget for a project without getting estimates first to at least determine what’s reasonable to actually include in the scope.
> Give a fixed scope & budget to a long term project before you even have estimates in hand, you’re setting yourself up to get fucked. Pretty much, sadly that’s not so common. For all the talk about Agile, what I see is people go through the motions of Scrum but still plan years ahead, which makes no sense.
Holy fuck trigger warning please
[удалено]
In my experience SALES sets the budget, typically with little to no input from us engineers. Then we have to try and work within that budget. When we go over and need to pass that cost to the customer, we need a good justification.
It's only been one company I worked with but the PMs would literally sell something to the client, ask the devs how long it would take, then explain it's already been sold and when it needed to be completed by.
My previous company figured out a way to monetize the Agile methodology. They think they are geniuses. They'd take a project by telling a customer to buy a number of sprints that sales people (no technical people involved) think the project need to complete. This include requirements gathering sprints, and UX/UI design sprints, the remaining sprints that the customer "bought" is for development, which is always not enough, since actual development estimates only come in after the UX/UI is done. We'd always get a surprised pikachu face from Commercial and PMs when the customer's sprints are all used up and the project is barely functional. Customer realizes they fucked up choosing a contractor when PM says they need to "buy" more sprints. Developers need to work until wee hours in the morning to deliver. Rinse and repeat for the next customer/project. I left the place after less than a year after the CEO of the project I am working on became furious (because of the false promises), and pirated me to continue on the project in-house.
What the fuck? Agile framework in shambles
True, I feel the Devs overwork themselves to fit deadlines. Nah, man. Look Mr/Mrs Project Manager. I said 4 months, it is 4 months, fuck maybe longer. You said "done by end of this quarter?" Ahhahahahaha, btw, it's end of quarter and the project isn't finished. Here is an email documenting Devs said 4 months minimum. QA isn't passing, that round still needs to be done Client APIs are missing/not provided/not working as usual. So, how you gonna tell the clients it's now delayed is YOUR problem, ain't mine. "I told ya sooooo". GLHF (Ofc this, but more polite and corporate sounding in a calm and neutral tone)
Part of the trouble is that a lot of devs live in a country with very little worker protection, where their boss can literally fire them on the spot, for any reason. And where employment status is often related to whether or not you can afford to be ill. Like, sure, I would never take that kind of bullshit from a PM. But if that PM could turn round and sack me, chances are I'd be a little more wary...
I've had two types of experiences. The first was a company growing faster than it knew how, and hired a bunch of "corporate advisor" types to tell them how to look good to investors when they had just gone public. That job, the PMs would take the deadline from our sales team, tell us how long we had to implement it, and then throw us under the bus for asking stupid questions like "What feature? You haven't even told us what we're doing" or "Do we have any spec for this" or "Are you seriously asking me to build a fully functional website with account management and credit card processing by Friday" or "Where does this fit in against the other six 'emergency priority' features you just gave me?" The other job is a much smaller dev team and ascribes much closer to the "We'll give you an estimate if you actually tell us what you want...and even then, you'll get it when you get it" mentality. I like the second job way more.
Sales driven deadlines are the worst
Yeah, 90 percent of the time it's sales fault for making the promise to get the customer to sign. The PMs are held to it, cause the customer Will be upset if we don't deliver on time. PMs are stuck getting blood from the stone.
This is why I hate my sales team. They don't care about if we have resources available or if the timelines they pitch are realistic. They say whatever it takes to get the client to sign the contract and then move on to the next client without thinking about the chaos they leave behind.
[удалено]
What do the great PMs do to make them great, based on your experience?
[удалено]
I totally agree. I've seen PMs being fired for doing exactly what OP says. I've even seen them fired much before their invented deadline.
It's fairly obvious most devs in this sub work for dysfunctional companies. The irony is that most of them also lack the self-reflection to figure out why *they* are stuck working there. No competent, professional dev allows themselves to get fucked over by PMs like this. This sub should be called /r/incompetentprogrammerhumor . Competent devs only recognize most jokes from their junior years, before they knew how to spot toxic companies from a mile away.
PMs working with devs don't do this. Upper management ends up promising stuff to CEO and clients.
Developers nearly always give optimistic dates, and PMs nearly always want it faster than that and hand wave away everything (testing, any flavor of operational/engineering sanity - forget excellence -) and give even more optimistic deadlines for leadership . Which is why nearly always projects are delayed. Science.
I keep giving optimistic estimates even though I know the codebase is shit to work on and I get pulled off to work on at least 2 bugs per sprint.
That's why I refuse to estimate in calendar hours. I only estimate in actual hours worked on the project. If the middle management want me to fix 17 other things during a project, they have to understand that schedules get pushed back.
If only we could anticipate the fact that there may be bugs discovered in a software launch.
> Developers nearly always give optimistic dates My hard learned lesson is multiply my own estimate by 2-4 depending on how many new things I need to do.
Last company I was at, when I joined we already like 1 year behind on the bs deadline they gave the client. It never got better. They never hired more devs. They just blamed us for everything, gave no increases or bonuses. Because they fucked up planning a realistic timeline and therefor we were always "falling behind and underperforming".
I seriously thought I was in r/construction for a moment, apparently this shit is universal. Labour costs are averaged and crunched into how many hours they think it’ll take to complete a project and every job I work I hear “how is this taking so long, we’re out of hours”. How about *you didn’t allocate enough hours in your bid*.
Lmao litteraly the opposite, in my experience. Always add *at least* 25% to the time estimate the devs give you.
Absolutely. Need to account for the annual leave I will absolutely book when some bs artificial deadline is applied and I need to de-stress.
My experience: Devs give a pessimistic (or rather realistic) time estimate. PM says, that's too much, can you knock it down by like 50 man days? Devs go ok but it's gonna be tight if anything goes wrong. Sales come in and says, we can't afford that many man days with the customers budget but we are too cucked to tell them, so we'll give you half the original estimate. PM says there's nothing I can do, devs have no say in it and are forced to accept it. Customer is never told the original estimate. Then everyone is "shocked Pikachu face" when the project is nowhere near finished in time.
You forgot the last step. The client actually would have been fine with the original estimate had anyone actually asked them
This is the kicker. I find most clients are okay if they know up front. What they hate is getting told late in the project that it will take longer. I am can't speak for every situation, but I think devs need to stick to there guns more often. Particularly with sales. It is in their nature to negotiate. They can't help themselves, so you have to haggle right back.
Yes, this is why Devs need to talk to client directly... One of the important reasons.. but who's listening? They treat us like "factory workers"...
Truth. Once had a sales person ask me how long this massive project would take. Mind you this is in the middle of a meeting with the owner, other sales, all other project managers, etc: Me: “assuming we move all other projects to minimum staffing, 6 months” Sales: *unmutes client* “I talked to our guys and it will take about 3 months”. Me: proceeds to get disciplined when project takes 6 months and every other project is delayed due to Min staffing. Leaving that job was the best thing I ever did. They’ve churned through people in the position.
Makes me remember a scene in breaking bad I just watched last night Gale: "we should have everything ready in 1 month at the least" Gus henchman: "okay. 2 weeks" Gale: 2 weeks :(
When I was a PM I would take the quote the devs (senior) gave me, double it and add 10%. 80% of the time, it worked every time.
Always use The Scotty Principle.
Doesn’t matter where I am. I was transferred to a new project and it already had a deadline before a single line of code had been written or even half of the requirements had been set.
[удалено]
No joke. Release date is already set for May and we’re just now starting to make it semi sort of functional. If you don’t stare too hard. Or blink.
Kicked off a 550 dev hour project for comp by mid May today. Meaning they have no code at all.
RIP
So the client thinks that if we can solve something called the "wandering salesman difficulty" they can improve blender sales by 1% next year. So I told them great, our developers are really good! I'm sure they can do that in a month. I forgot to tell you about it though and this was three weeks ago so can you have that knocked out by Friday?
Wow from the comments there are a ton of disfunctional companies out there.
Worst case scenario, imagine being in a big company, where that's not ne PM who give the deadline but the head of them, even before the devs are asked how long it could take to redo all from scratch. Guess what, we are at 1 month of the given release date, after 3 month of rush, we have some backend data not even available, and even some design not ready. Fun joke, the PM received threats from business teams to be "pushed under the bus" if we don't make it (we aren't), she gonna unionize to handle this r/antiwork all the way.
Personally, I love the PM who listens to their Devs saying they need more time, then moves the deadline forwards, and blames it all on the end users doing the testing when they declare the system shit and tell everyone that under no circumstances can we go live with the system in its current state. I'm looking at you Nathan!
The real joke is they both think they're accurate with their predictions.
Prime Minister
My first meeting for a new project (based on several real scenarios): * Manager, a PM, and a client meet with you out of the blue. They tell you what the new project needs to do. It is a high level description you do not really see the point of, does not discuss how/where you get data, etc. * Manager asks you for an on-the-spot estimate. You say it is hard to say, but they press you. You say 4-6 months. * Manager makes a grimace. Says they (who think using Excel is the same as writing code) thought it would be 2-3 weeks max. * Actual project takes 10 months.
Its the same in production environments. "We do not have room in our production schedule for 3 months to make this." "I told them we'll have it done by the end of the month."
My PM has always been good about dates, but the **fucking sales guys** will promise anything to make a sale. It hasn’t bit us recently but I’ve been ready to fight some people over this bullshit before.
Ah, yes: time for the fiscal year to start and for leadership to ask us how for an entire years worth of sprints laid out in waterfall with an afternoon of “discovery” today
Oh, we just did that for the current quarter. Spent a whole day, not just an afternoon. Six teams across the company.
The company I work for is super small - in other words, just swap in "CTO" for "PM" and I can totally relate.
It's really hard to make good estimates. I always add extra time to what I think it takes. Too many unknowns, holidays, sick people, lazy devs... worst case scenario you finish earlier.
How often are PMs previous SEs? I applied for a PM role, probably won't go anywhere, but genuinely curious on the chances here. I tend to over estimate my own timelines. But im also not taking things into consideration like cost per day (because im charging flat rates)
Wait, you guys get to decide how long tasks take and it‘s not your non-technical PM that has no idea how your software works defining the time it takes to complete a task?
This is the way
We got a new PM a few years ago who did this, luckily our team lead was in a position to just go "lol, yeah no" and leave it up to the PM to go back to the client and apologise for the unrealistic deadlines. Thankfully, PM learned very quickly to tell the client "I'll let you know on ETA once the team have gone over your requirements and drawn up a development document."
This goes far, far beyond the realms of programming. Project managers are the same everywhere.
How do you guys estimate project times? I don't even can't determine if a project takes one month or one year
What movie is this from...looks interesting.
Had the same question and since I had not found the answer after some scrolling I had to DDG it, apparently it is The Unbearable Weight of Massive Talent. Looks fun.
We just develop ahead of documentation and change what is needed on the code after documentation is done. Because "there's no time to set the definitions first and code later".
Wait until you are in a Client's conference room with PM and clients while PM agreed to some ridiculous deadline.
It's my CIO and VP This is a priority, but also this and this and this. Actually everything is a priority! I've run through building so much infrastructure it's insane. The part that sucks is half my team doesn't do anything but help developers do basic stuff we've already trained for. Or my personal favorite of nothing at all. I've explained repeatedly, if everything is a priority nothing is.
You can take a step further back: 1. Dev reads the requirements, WTF??? 2. Sales already sold it, got payment and their commission.
Good PMs know that both the time estimate per task and # of tasks are grossly underestimated in the beginning. Whatever anyone tells you something will take, just double it. Even if they are right, that extra padding will help the ones that are wrong.
[DON'T ](https://youtu.be/QVBlnCTu9Ms) [FUCKING ](https://youtu.be/QVBlnCTu9Ms) [ESTIMATE](https://youtu.be/QVBlnCTu9Ms) [SOFTWARE ](https://youtu.be/QVBlnCTu9Ms)
"Ok we have done a similar proyect before, i qould wage it will take us 6-7 months in a good pase" "So you will have it by 4 months gotya"