⬅️ Meta Programming ⬅️ Pointer 🔗 From here
- Good estimation provides predictability.
- When asked to provide an estimate of something big, the most honest thing to do is to stall. Most engineers are enthusiastic and eager to please, and stalling certainly will displease the stalled. But an on-the-spot estimate probably won’t be accurate and honest.
- While stalling, it may be possible to consider doing or prototyping the task. If political pressure permits, this is the most accurate way of producing the estimate, and it makes real progress.
- Pad explicitly instead of implicitly. If a task will probably take one day - but might take ten days if your approach doesn’t work - note this somehow in the estimate if you can; if not, at least do an average weighted by your estimates of the probabilities. Any risk factor that you can identify and assign an estimate to, should go into the schedule.
🔗 From Yes, You Should Estimate Software Projects
- Estimates matter because most people and businesses are date-driven.
- How and when the delay is communicated matters far more than the delay itself.
- Estimates and deadlines are great for getting things done. They heavily incentivize teams to focus.
- Giving estimates, than missing them forces deeper reflection and faster learning about the types of unknowns in the software world.
- Estimating and being deadline-driven is a lot less comfortable than choosing not to estimate. But this is not an excuse to not grow your estimations skill.