In software as in everyday life, estimating time is hard. For software in particular my typical response to "how long will it take?" type questions is:
what do you want this information for?
and,
do you want a more accurate estimate than a number out of a hat? If yes, then I will have to do a deep analysis of the problem, constraints and assumptions, architecture, breakdown of dependencies, team availability and skills in that area, to give you an estimate which should be in the ballpark.
By this point their eyes glaze over and they go, "number out of a hat is fine, I just need to put some numbers on a roadmap for my presentation to the board next week!" at which point I oblige them duly with a number that's on purpose a bit bloated and everyone is happy. No expectations are broken, no business loss occurs and developers are not flogged to go "faster"!
I have also found that once an engineering effort is underway, keeping people in the loop about progress or even impedances every sprint via show and tells and demos, is the most effective way to have them stop asking such questions to begin with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In software as in everyday life, estimating time is hard. For software in particular my typical response to "how long will it take?" type questions is:
By this point their eyes glaze over and they go, "number out of a hat is fine, I just need to put some numbers on a roadmap for my presentation to the board next week!" at which point I oblige them duly with a number that's on purpose a bit bloated and everyone is happy. No expectations are broken, no business loss occurs and developers are not flogged to go "faster"!
I have also found that once an engineering effort is underway, keeping people in the loop about progress or even impedances every sprint via show and tells and demos, is the most effective way to have them stop asking such questions to begin with.