←back to thread

318 points alexzeitler | 1 comments | | HN request time: 0.202s | source
Show context
avidiax ◴[] No.42188764[source]
One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns.

You should not provide an estimate for "feature X implemented", but rather for "feature X engine". If you discover additional work to be done, then you need to add "existing code refactor", "feature X+Y integration", etc. as discovered milestones.

Unfortunately, you need that nomenclature and understanding to go up the chain for this to work. If someone turns your "feature X engine" milestone into "feature X complete" with the same estimate, you are screwed.

------

There is a related problem that I've seen in my career: leadership thinks that deadlines are "motivating".

These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster".

I was once in a leadership meeting, where the other participants forgot that I, lowly engineer, was invited to this meeting. Someone asked if we should accept that deadline X was very unlikely to be met, and substitute a more realistic deadline. To which the senior PM responded that "we never move deadlines! Engineering will just take any time given to them!"

Engineering, in that case, gave the time back when I left that team.

replies(2): >>42191978 #>>42192931 #
1. rightbyte ◴[] No.42192931[source]
> These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster".

This usually works though in water based heating systems where the flow in the radiators is proportional to the error in temperature.

In practice it might work for electrical radiators too, as the radiator wont cut off when just the air close to it is warm.