7 ms·

Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate

Honest question. Say you have a project. Your boss expects it can be done in two weeks. Let's say you are good at estimating your own velocity, and you estimate four weeks for that project. Do you: a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? b) Tell your boss it will take two weeks and then blame delays when the deadline passes? or c) Tell your boss it will take two weeks, then cut corners to deliver a finished project in two weeks, but one that is so lacking that someone (possibly not you) will need at least 4 more weeks undoing and fixing stuff at a later stage? (Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b)

ohgodplsno 6y ago
> Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b) So, you've never seen someone being a professional ? I've told my boss plenty of times his estimates are wrong, and that it will take longer. It's my job to know how long things take. If my boss thinks it can be done shorter, he better 1/ have the same work experience that I do and 2/ do it on his own.
zepolen 6y ago
d) Tell your boss it will take 6 weeks, deliver in 4
- pmiller2 6y ago
  I see you're from the Montgomery Scott school of estimation.
irjustin 6y ago
Where's D where we talk it out and why we currently disagree on the expectation difference? Isn't that how it's supposed to be?
- wccrawford 6y ago
  For me, it's not even that. I've never had a boss tell me what it'll take. I've always been asked, even though I've repeatedly told them I'm horrible at estimates. Thought sometimes they'll suggest a timeframe, hopefully. When I tell them that they were too optimistic, their usual reply is that I need to get back to them as soon as anything changes for the worse. Otherwise, truck along and do it. If I say 'nope, 4 weeks' right off the bat, there's usually a step where they consider if it'll be worth it in that time (or possibly longer) and they tell me when to ditch it and move on, if it's really going to be that long. And it happens sometimes, even on projects that I really wanted to do. The opposite happens, too, though. Sometimes they think it'll take longer than I think, and I tell them in that situation, too.
conradludgate 6y ago
At my job, our PMs don't suggest any time frames, they ask all the devs for the expected effort instead. More discussion and agreement then by the people actually qualified to say. Of course we do still have some deadlines but that's also not in the PMs control as they're external factors
- TameAntelope 6y ago
  Yeah, the most helpful answer is a, but with a follow up explaining what you can do in two weeks, and you let the boss decide if that’s good enough, if there’s more resources available, or if you should work on something else with that time instead.
xxs 6y ago
0 - your boss is a smart one and actually knows how to use Pi properly as an estimation multiplier. About your honest part - your boss should really have a lot better estimation of your skills (or he sucks at that too). I suppose you're preoccupied with their opinion of you rather than getting the job completed.
vishnugupta 6y ago
I (as a manager) always get a push-back when I try to impose my timelines on my team. Though we do have a healthy conversation as a result and we end up uncovering a bunch of unknowns which I then take it to my boss to inform them. When an engineer says they need 4 weeks instead of 2 it's my responsibility as a manager to get into the details, not as a way to micro-manage but to help my team be more confident about the 4 weeks timelines. Often times the engineers have a "gut" feeling but aren't sure about "why" so I push them to spell out that "why". To answer your question; "b" is just about the worst possible option. It not only makes you look bad but also the whole team will get labelled; remember that your boss also has someone to answer to and it'll make them also look bad. Never keep your boss/manager in the dark. Push back with data and educate them as to why it takes 4 weeks instead of 2.
- BlargMcLarg 6y ago
  Real question: do you actually believe this to be positive more so than negative most of the time? Many people will feel resentment over what is essentially continuous doubt and having to spend time to push back that could be spent thinking about the problem, diving in and making a better idea later. Additionally, your way of presenting the argument seems harmless and emotionless, yet reality is often far away from this. A slew of social dynamics take place which make developers say things to get managers out of their hair more than truly having a discussion on how long it takes. The far majority of managers also impose these deadlines without clear rime or reason ("because the customer wants it"/"because sales said so", at best). What's really going to happen if we estimate higher and end up overdelivering at the end? Are you truly going to lose customers, or are you just trying to pressure people in "being accurate", which often devolves more into having one's subordinates take the blame and the fall for underdelivering? With all due respect, it feels like we are normalizing things for the sake of manager's security without much reciprocation (only make-believe that it is being reciprocated).
  - KSteffensen 6y ago
    It's the managers duty to create the trust needed for having a constructive discussion of task breakdowns and timelines. If the engineer is "just saying things to get the managers out of their hair" the manager has failed at this. You seem to dismiss entirely that doing a proper task breakdown is a way to think about the problem, revealing unknowns, clarifying requirements and making sure as many steps along the way as possible are clear and actionable. In an ASIC project, if you miss your tape-out deadline, your time to market will be delayed by several months until the fab can find a new slot to fit you in. This can cost many millions of dollars. Accurate development estimates are important.
hrktb 6y ago
a) happens routinely. It's not just that you effectively suck, your boss also sucks and needs to learn from it. Basically a) is your chance to recalibrate the expectations, and if you don't do it you'll be stuck forever meeting random deadlines (well, even if you do it you're still not out of that cycle, but at least you're setting precedents)
kwhitefoot 6y ago
Not quite what you are asking but related: Many years ago my boss handed me the notes that he had made in a meeting with a customer and asked me to work out a project plan to create the hardware, drawings, software, etc. I did that and gave it to him. The next day he called me into his office and told me that he and the customer had already agreed a delivery date and that I had to edit the plan so that it would be delivered on that date. That date was two months earlier than my estimate, 20% less elapsed time. I tried to argue that we didn't have the necessary resources (software developers, hardware development, circuit board design and manufacturing, prototyping, etc.) to do it any faster but he insisted. So in the absence of any way to cut the time in a way that really made sense I just cut about 20% off each of the items on critical path of the Gantt chart and gave it back to him. He seemed happy then but he was much less happy when we delivered on time and under budget according to my original estimate.
torgard 6y ago
I go with a) every time. I would find anything else to be unprofessional. I don't "effectively suck", I disagree with them on the timing. I'll explain my reasoning, and if they cannot accept that, then it's out of my hands; they have chosen to cut corners.
- b0afc375b5 6y ago
  I go with a) as well, and I add a very generous time allowance on top of my estimate. But you can't really do much when you're told to 'get it done this week'. First to go out the window is TDD, of course.
- Gravyness 6y ago
  Have seen companies fire people for that. Sometimes you can't afford that.
  - torgard 6y ago
    If a company chose to fire me for that, I would not want to work at that company anyhow. I know this is somewhat naive; not everyone is in a position where they can pick and choose what companies they wish to work at. But still, such a company would be a terrible company to work at.
kumaranv 6y ago
I have seen the effects of not saying 'a'. People even asked to leave the company because of simply agreeing to finish as asked. When we agree to it, our head will roll unless the company never cares about missing deadlines. Another approach which I follow nowadays is, agree but tell them that most probably I will miss the deadline.
rytis 6y ago
Usually this has a tendency to propagate, in my experience. The deadlines come from above and/or externally dictated. So even if you have balls to say a), your boss (or your boss' boss, etc) may not, or they might have different agenda, that has nothing to do with the quality of the deliverables.
tremon 6y ago
Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? No, I tell my boss that he sucks and it will take me 4 weeks instead of 2.
- tpoacher 6y ago
  hahah, I like this.
px1999 6y ago
Never seeing A is IMO a bit of a red flag. A+C is probably the most common where I'm at (enterprise SaaS), though its usually with management's knowledge/understanding. We wind up rushing something out to meet the client's direct need to hit their deadline, then figure out generalisation afterwards (which admittedly does drag out and has its own issues). As a genuine question, is this approach abnormal or bad? I'm on the technical management side of the whole thing - am I screwing my staff by encouraging this? We want to shorten that generalisation process but that (internal) pressure to just close it out seems like the lesser of two evils when compared to the sorts of pressure that clients paying significant $$$ apply
koonsolo 6y ago
Old timer here, and I struggled with this when I was younger. But I figured it out by working at a lot of different places. I always get great reviews and am considered a highly valued programmer, so you can depend on this advice :). When your manager (never say "boss", because you are your own boss, they are the manager) says "2 weeks", at that point it's their responsibility. So as long as you don't say "I can do it in 2 weeks", it remains their responsibility. So an easy way to respond is "I'll do my best", or "I'll see what I can do". In your head, you say "YOU said 2 weeks, NOT me. So if it takes longer, it's YOUR fault, not MINE". And then you work on the project like any other project. It's not about you being bad at your job, it's about the person being a bad manager. Keep the manager up to date on the progress. Next step is to educate your manager. Don't fall in the trap of making estimates in 5 seconds on the spot. In this case, you could respond "2 weeks? I don't know, I haven't made an estimate on that." This way you indicate that YOU are the person who should do the estimate, not them. You could follow up with "Do you want me to make a detailed estimate?". If no, then indicate "ok, I'll see what I can do" as above. If yes, make a realistic deadline (NOT estimate, see below). Bad managers come with all kinds of tricks to pressure you, like for example "The customer expects this to be ready in 2 weeks". At that point, you really need to educate them and show how reality works: "Wow, I hope for your sake that you made a correct estimate. I didn't estimate the work, so I have no clue if this is possible. But you might be in a lot of trouble when you made the wrong call here". See what I did here? Managers try to push problems on you, don't let this happen. Always make it clear that the responsibility is always in their camp as long as you didn't make the estimate. If the 2 week deadline is not met, it's their fault of not asking you for a proper estimate in the first place, secondly for making a wrong estimate themselves, and never because you are bad at your job and should work overtime. Don't let bad management be your fault, because it isn't. So when you can make estimates yourself, make sure you know the difference between an estimate and a deadline. Most managers think it's the same. An estimate is "I think it takes around 4 weeks", which basically means "Best case it takes 3 (which it never will), and something might go wrong so it could be 6 weeks". A deadline always has a buffer built in. It's a worst case scenario. Your manager will ask for an "estimate", but 99% of the time it will be a deadline. So make sure your "estimate"=deadline includes a buffer of worst case scenario. If you estimate 4 weeks, they will promise it to the customer in 4 weeks. This is wrong of course, since there is no buffer. So say 6. And this is how you keep your sanity as a developer. Educate your managers, because a lot of them are not really knowledgeable and experienced in dealing with proper software development.
ClumsyPilot 6y ago
I think enough folks have covered the fact that you should be able to discuss how long things take with your boss. However i want to make a point about cutting corners - in my experience, its a jusdgement call on what's essential, and whihc corners can be cut. I've seen engineers spend loads of time on things that in the end did not matter, etc. So I would say that's an inportant conversarion to have.
blablabla123 6y ago
> a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? Assuming the company hired me because they had a gap to fill that I fit in and also that I delivered so far in reasonable velocity: if it's really so pressing yet unpredictable to deliver, I'd take the time to analyze the task and explain the boss what parts would take how long and why. If it's a good boss, he or she will either prioritize sub-tasks or talk to the other stakeholders and change requirements, i.e. adapt requirements to reality. If you work for a good boss/team/company, the effect afterwards will be that everybody will be more happy. Also on the long-term the project will be successful. So if making such a statement implies "you effectively suck", consider changing workplaces because this is unreasonable and even toxic. (Although even the most toxic places will give in if you have the patience and confidence to explain. If not, they'll definitely make sure to blame it on you.)
arethuza 6y ago
As someone who has been in the "boss" role on and off for a long time I have a policy of never trying to argue developers down on estimates - I usually argue up as, at least in my experience, most developers are fairly optimistic at what can be achieved in a given time.
wernercd 6y ago
d) Tell your boss what can be done realistically in 2 weeks and what timeframe it will take to do the full "Project". You have two things... a request and a time frame. If they don't match? Admitting you suck isn't a realistic option. It's a lie to start with and it helps no one. Lying to your boss ("Sure, I'll get what I said would take 4 months done in two weeks") helps no one either. Helps if you have some "street cred" to back up your claims... and you won't get that by saying "I suck" or "Sure thing boss".
pdimitar 6y ago
d) Tell my boss that THEY effectively suck at estimating and it will take 4 weeks. If they want less, I'll not sign under unprofessional work and they can get somebody else to do it.
- walterlb 6y ago
  My manager sometimes makes commitments to stakeholders on the spot when he agrees to take on the work, without consulting with the developer (me, in these cases). Often the requirements are not even clear yet. It's not comfortable to do, but I will jump in and veto his commitments right there if they are clearly not attainable. The stakeholders tend to be accepting of the fact that things are more complex to implement than just: "make the software do X", but my (technical) manager always seems a bit baffled. In the long run, I know he values this about me, but it frustrates me to no end.
  - pdimitar 6y ago
    Yeah, I get that blind enthusiasm sometimes but I've learned to control it. I show enthusiasm on my face -- and it's genuine! -- but I don't rush into promising. I found that to be the best balance because (a) people like it when you genuinely care and (b) you still don't come off as a pushover that accepts any demands for budget and schedule on the spot.
Foobar8568 6y ago
I always do a, and that's why people think that I am slow and I don't have a great career...But at least I deliver stuff that works. At my previous client, I had a "IT supplier team lead" that kept promising stuff delivered in x days even tho that x months later, the stuff wasn't working. He was seen as a god. Nobody called on his bullshit but me, later on, management was telling me that I wasn't a team player, good stuff.
- tpoacher 6y ago
  yes, alas, that's exactly my point. The only peoply who are conscientious enough to go for (a) are also typically the same people who will pick up all the bullshit from people doing (b) and (c).
magicalhippo 6y ago
d) Explain to my boss why I think it will take four weeks rather than two. We'll then have a discussion and come up with a hopefully more realistic estimate. This might include finding a different solution to the problem. Sometimes it has to be done in two weeks, and then the issue is what we can do in two weeks. Other times it's just a bigger problem than what my boss assumed. And yet again maybe I'm overthinking things and it can actually be done in two weeks.
spaetzleesser 6y ago
a) has the implication that you suck if you can't do it in two weeks. It's pretty sad that we can't state the cold, hard facts but have to lie.
majkinetor 6y ago
d) because nobody knows how much non-trivial project takes until its done. Its well known that developers missestimate time needed by the factor of 4 to 8. So d) which you miss, is about 4 months. Anything else is not professional and you cut corners. There is no such thing as 2 weeks in enterprise - hello world would take more with adequate docs, ci/cd, metrics, proj. management, optimizations, authorizations etc.

ohgodplsno 6y ago

> Note: I have NEVER seen anyone do 'a'. It's usually a creative hybrid between a and b) So, you've never seen someone being a professional ? I've told my boss plenty of times his estimates are wrong, and that it will take longer. It's my job to know how long things take. If my boss thinks it can be done shorter, he better 1/ have the same work experience that I do and 2/ do it on his own.

zepolen 6y ago

d) Tell your boss it will take 6 weeks, deliver in 4

pmiller2 6y ago
I see you're from the Montgomery Scott school of estimation.

irjustin 6y ago

Where's D where we talk it out and why we currently disagree on the expectation difference? Isn't that how it's supposed to be?

wccrawford 6y ago
For me, it's not even that. I've never had a boss tell me what it'll take. I've always been asked, even though I've repeatedly told them I'm horrible at estimates. Thought sometimes they'll suggest a timeframe, hopefully. When I tell them that they were too optimistic, their usual reply is that I need to get back to them as soon as anything changes for the worse. Otherwise, truck along and do it. If I say 'nope, 4 weeks' right off the bat, there's usually a step where they consider if it'll be worth it in that time (or possibly longer) and they tell me when to ditch it and move on, if it's really going to be that long. And it happens sometimes, even on projects that I really wanted to do. The opposite happens, too, though. Sometimes they think it'll take longer than I think, and I tell them in that situation, too.

conradludgate 6y ago

At my job, our PMs don't suggest any time frames, they ask all the devs for the expected effort instead. More discussion and agreement then by the people actually qualified to say. Of course we do still have some deadlines but that's also not in the PMs control as they're external factors

TameAntelope 6y ago
Yeah, the most helpful answer is a, but with a follow up explaining what you can do in two weeks, and you let the boss decide if that’s good enough, if there’s more resources available, or if you should work on something else with that time instead.

xxs 6y ago

0 - your boss is a smart one and actually knows how to use Pi properly as an estimation multiplier. About your honest part - your boss should really have a lot better estimation of your skills (or he sucks at that too). I suppose you're preoccupied with their opinion of you rather than getting the job completed.

vishnugupta 6y ago

I (as a manager) always get a push-back when I try to impose my timelines on my team. Though we do have a healthy conversation as a result and we end up uncovering a bunch of unknowns which I then take it to my boss to inform them. When an engineer says they need 4 weeks instead of 2 it's my responsibility as a manager to get into the details, not as a way to micro-manage but to help my team be more confident about the 4 weeks timelines. Often times the engineers have a "gut" feeling but aren't sure about "why" so I push them to spell out that "why". To answer your question; "b" is just about the worst possible option. It not only makes you look bad but also the whole team will get labelled; remember that your boss also has someone to answer to and it'll make them also look bad. Never keep your boss/manager in the dark. Push back with data and educate them as to why it takes 4 weeks instead of 2.

BlargMcLarg 6y ago
Real question: do you actually believe this to be positive more so than negative most of the time? Many people will feel resentment over what is essentially continuous doubt and having to spend time to push back that could be spent thinking about the problem, diving in and making a better idea later. Additionally, your way of presenting the argument seems harmless and emotionless, yet reality is often far away from this. A slew of social dynamics take place which make developers say things to get managers out of their hair more than truly having a discussion on how long it takes. The far majority of managers also impose these deadlines without clear rime or reason ("because the customer wants it"/"because sales said so", at best). What's really going to happen if we estimate higher and end up overdelivering at the end? Are you truly going to lose customers, or are you just trying to pressure people in "being accurate", which often devolves more into having one's subordinates take the blame and the fall for underdelivering? With all due respect, it feels like we are normalizing things for the sake of manager's security without much reciprocation (only make-believe that it is being reciprocated).
- KSteffensen 6y ago
  It's the managers duty to create the trust needed for having a constructive discussion of task breakdowns and timelines. If the engineer is "just saying things to get the managers out of their hair" the manager has failed at this. You seem to dismiss entirely that doing a proper task breakdown is a way to think about the problem, revealing unknowns, clarifying requirements and making sure as many steps along the way as possible are clear and actionable. In an ASIC project, if you miss your tape-out deadline, your time to market will be delayed by several months until the fab can find a new slot to fit you in. This can cost many millions of dollars. Accurate development estimates are important.

hrktb 6y ago

a) happens routinely. It's not just that you effectively suck, your boss also sucks and needs to learn from it. Basically a) is your chance to recalibrate the expectations, and if you don't do it you'll be stuck forever meeting random deadlines (well, even if you do it you're still not out of that cycle, but at least you're setting precedents)

kwhitefoot 6y ago

Not quite what you are asking but related: Many years ago my boss handed me the notes that he had made in a meeting with a customer and asked me to work out a project plan to create the hardware, drawings, software, etc. I did that and gave it to him. The next day he called me into his office and told me that he and the customer had already agreed a delivery date and that I had to edit the plan so that it would be delivered on that date. That date was two months earlier than my estimate, 20% less elapsed time. I tried to argue that we didn't have the necessary resources (software developers, hardware development, circuit board design and manufacturing, prototyping, etc.) to do it any faster but he insisted. So in the absence of any way to cut the time in a way that really made sense I just cut about 20% off each of the items on critical path of the Gantt chart and gave it back to him. He seemed happy then but he was much less happy when we delivered on time and under budget according to my original estimate.

torgard 6y ago

I go with a) every time. I would find anything else to be unprofessional. I don't "effectively suck", I disagree with them on the timing. I'll explain my reasoning, and if they cannot accept that, then it's out of my hands; they have chosen to cut corners.

b0afc375b5 6y ago
I go with a) as well, and I add a very generous time allowance on top of my estimate. But you can't really do much when you're told to 'get it done this week'. First to go out the window is TDD, of course.
Gravyness 6y ago
Have seen companies fire people for that. Sometimes you can't afford that.
- torgard 6y ago
  If a company chose to fire me for that, I would not want to work at that company anyhow. I know this is somewhat naive; not everyone is in a position where they can pick and choose what companies they wish to work at. But still, such a company would be a terrible company to work at.

kumaranv 6y ago

I have seen the effects of not saying 'a'. People even asked to leave the company because of simply agreeing to finish as asked. When we agree to it, our head will roll unless the company never cares about missing deadlines. Another approach which I follow nowadays is, agree but tell them that most probably I will miss the deadline.

rytis 6y ago

Usually this has a tendency to propagate, in my experience. The deadlines come from above and/or externally dictated. So even if you have balls to say a), your boss (or your boss' boss, etc) may not, or they might have different agenda, that has nothing to do with the quality of the deliverables.

tremon 6y ago

Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? No, I tell my boss that he sucks and it will take me 4 weeks instead of 2.

tpoacher 6y ago
hahah, I like this.

px1999 6y ago

Never seeing A is IMO a bit of a red flag. A+C is probably the most common where I'm at (enterprise SaaS), though its usually with management's knowledge/understanding. We wind up rushing something out to meet the client's direct need to hit their deadline, then figure out generalisation afterwards (which admittedly does drag out and has its own issues). As a genuine question, is this approach abnormal or bad? I'm on the technical management side of the whole thing - am I screwing my staff by encouraging this? We want to shorten that generalisation process but that (internal) pressure to just close it out seems like the lesser of two evils when compared to the sorts of pressure that clients paying significant $$$ apply

koonsolo 6y ago

Old timer here, and I struggled with this when I was younger. But I figured it out by working at a lot of different places. I always get great reviews and am considered a highly valued programmer, so you can depend on this advice :). When your manager (never say "boss", because you are your own boss, they are the manager) says "2 weeks", at that point it's their responsibility. So as long as you don't say "I can do it in 2 weeks", it remains their responsibility. So an easy way to respond is "I'll do my best", or "I'll see what I can do". In your head, you say "YOU said 2 weeks, NOT me. So if it takes longer, it's YOUR fault, not MINE". And then you work on the project like any other project. It's not about you being bad at your job, it's about the person being a bad manager. Keep the manager up to date on the progress. Next step is to educate your manager. Don't fall in the trap of making estimates in 5 seconds on the spot. In this case, you could respond "2 weeks? I don't know, I haven't made an estimate on that." This way you indicate that YOU are the person who should do the estimate, not them. You could follow up with "Do you want me to make a detailed estimate?". If no, then indicate "ok, I'll see what I can do" as above. If yes, make a realistic deadline (NOT estimate, see below). Bad managers come with all kinds of tricks to pressure you, like for example "The customer expects this to be ready in 2 weeks". At that point, you really need to educate them and show how reality works: "Wow, I hope for your sake that you made a correct estimate. I didn't estimate the work, so I have no clue if this is possible. But you might be in a lot of trouble when you made the wrong call here". See what I did here? Managers try to push problems on you, don't let this happen. Always make it clear that the responsibility is always in their camp as long as you didn't make the estimate. If the 2 week deadline is not met, it's their fault of not asking you for a proper estimate in the first place, secondly for making a wrong estimate themselves, and never because you are bad at your job and should work overtime. Don't let bad management be your fault, because it isn't. So when you can make estimates yourself, make sure you know the difference between an estimate and a deadline. Most managers think it's the same. An estimate is "I think it takes around 4 weeks", which basically means "Best case it takes 3 (which it never will), and something might go wrong so it could be 6 weeks". A deadline always has a buffer built in. It's a worst case scenario. Your manager will ask for an "estimate", but 99% of the time it will be a deadline. So make sure your "estimate"=deadline includes a buffer of worst case scenario. If you estimate 4 weeks, they will promise it to the customer in 4 weeks. This is wrong of course, since there is no buffer. So say 6. And this is how you keep your sanity as a developer. Educate your managers, because a lot of them are not really knowledgeable and experienced in dealing with proper software development.

ClumsyPilot 6y ago

I think enough folks have covered the fact that you should be able to discuss how long things take with your boss. However i want to make a point about cutting corners - in my experience, its a jusdgement call on what's essential, and whihc corners can be cut. I've seen engineers spend loads of time on things that in the end did not matter, etc. So I would say that's an inportant conversarion to have.

blablabla123 6y ago

> a) Tell your boss that you effectively suck and it will take you 4 weeks instead of 2? Assuming the company hired me because they had a gap to fill that I fit in and also that I delivered so far in reasonable velocity: if it's really so pressing yet unpredictable to deliver, I'd take the time to analyze the task and explain the boss what parts would take how long and why. If it's a good boss, he or she will either prioritize sub-tasks or talk to the other stakeholders and change requirements, i.e. adapt requirements to reality. If you work for a good boss/team/company, the effect afterwards will be that everybody will be more happy. Also on the long-term the project will be successful. So if making such a statement implies "you effectively suck", consider changing workplaces because this is unreasonable and even toxic. (Although even the most toxic places will give in if you have the patience and confidence to explain. If not, they'll definitely make sure to blame it on you.)

arethuza 6y ago

As someone who has been in the "boss" role on and off for a long time I have a policy of never trying to argue developers down on estimates - I usually argue up as, at least in my experience, most developers are fairly optimistic at what can be achieved in a given time.

wernercd 6y ago

d) Tell your boss what can be done realistically in 2 weeks and what timeframe it will take to do the full "Project". You have two things... a request and a time frame. If they don't match? Admitting you suck isn't a realistic option. It's a lie to start with and it helps no one. Lying to your boss ("Sure, I'll get what I said would take 4 months done in two weeks") helps no one either. Helps if you have some "street cred" to back up your claims... and you won't get that by saying "I suck" or "Sure thing boss".

pdimitar 6y ago

d) Tell my boss that THEY effectively suck at estimating and it will take 4 weeks. If they want less, I'll not sign under unprofessional work and they can get somebody else to do it.

walterlb 6y ago
My manager sometimes makes commitments to stakeholders on the spot when he agrees to take on the work, without consulting with the developer (me, in these cases). Often the requirements are not even clear yet. It's not comfortable to do, but I will jump in and veto his commitments right there if they are clearly not attainable. The stakeholders tend to be accepting of the fact that things are more complex to implement than just: "make the software do X", but my (technical) manager always seems a bit baffled. In the long run, I know he values this about me, but it frustrates me to no end.
- pdimitar 6y ago
  Yeah, I get that blind enthusiasm sometimes but I've learned to control it. I show enthusiasm on my face -- and it's genuine! -- but I don't rush into promising. I found that to be the best balance because (a) people like it when you genuinely care and (b) you still don't come off as a pushover that accepts any demands for budget and schedule on the spot.

Foobar8568 6y ago

I always do a, and that's why people think that I am slow and I don't have a great career...But at least I deliver stuff that works. At my previous client, I had a "IT supplier team lead" that kept promising stuff delivered in x days even tho that x months later, the stuff wasn't working. He was seen as a god. Nobody called on his bullshit but me, later on, management was telling me that I wasn't a team player, good stuff.

tpoacher 6y ago
yes, alas, that's exactly my point. The only peoply who are conscientious enough to go for (a) are also typically the same people who will pick up all the bullshit from people doing (b) and (c).

magicalhippo 6y ago

d) Explain to my boss why I think it will take four weeks rather than two. We'll then have a discussion and come up with a hopefully more realistic estimate. This might include finding a different solution to the problem. Sometimes it has to be done in two weeks, and then the issue is what we can do in two weeks. Other times it's just a bigger problem than what my boss assumed. And yet again maybe I'm overthinking things and it can actually be done in two weeks.

spaetzleesser 6y ago

a) has the implication that you suck if you can't do it in two weeks. It's pretty sad that we can't state the cold, hard facts but have to lie.

majkinetor 6y ago

d) because nobody knows how much non-trivial project takes until its done. Its well known that developers missestimate time needed by the factor of 4 to 8. So d) which you miss, is about 4 months. Anything else is not professional and you cut corners. There is no such thing as 2 weeks in enterprise - hello world would take more with adequate docs, ci/cd, metrics, proj. management, optimizations, authorizations etc.