Ask HN: What questions do you ask yourself when estimating programming tasks?

If this type of work has been done previous, you could reference that ticket for a general guideline on how long that item took. Otherwise think about how long it would take you to accomplish given your knowledge and experience then account for the developers knowledge and experience, and pad the time a little bit, also account for other departments involved. A lot of times we build part of the task for a quick estimate of how long that took (nothing more than an hour). Also if there are any examples or existing proof of concepts that can be used to accelerate the dev time. And lastly remember that its only an estimate.

If there is anything you can easily count or estimate, do it. It may be wildly inaccurate, but it's better than nothing, and those paying for the job also have a hard time arguing about counts.

Examples:

If there is UI involved, count or estimate the screens and their complexity (# of controls, plus a factor for what your gut says the complexity of each control is)

If you have to process xml, json or something like it, count the number of different tags in the file. Again, add or multiply by what your gut/experience tells you the complexity of the structure or what you have to do with it is.

Similarly, for a database, guess/count tables, fields and foreign keys.

If there are N stakeholders, multiply your estimate by f(N) for some strictly increasing f (they won't accept f(x) = x, but square root works fine). if they complain, saying they will not disagree, ask them to appoint a single stakeholder so that the others don't need to waste time saying what that single stakeholder would say, anyways.

Number one question: What don't I know yet?

Known unknowns are what make an estimate a range. Unknown unknowns are what will make it completely useless.

For the known unknowns, make them knowns. Put together best and worst case scenarios. Weight your estimate towards the worst-case scenarios.

Unknown unknowns, well... the trick is to turn as many of them as possible into known unknowns. Skim through the code you're extending, or sketch yourself a diagram of what you're building from scratch. Check your assumptions about APIs or available data. If it's a small project, have an idea as close as possible to exactly what lines you'll have to write/change to accomplish your task. If it's a very large project, write the tiniest possible proof of concept of the riskiest portion to validate your assumptions before giving an estimate.

Make yourself a checklist of steps to complete your task. Break those down into at least three sub-steps for each step. Then break those steps down further until you're down to tasks that will take no more than two hours apiece to complete.

Don't forget to include time for writing automated tests; for manual testing; and for fixing things that don't work the way you intended the first time around.

If you're being asked for a turnaround time estimate rather than a person-hours estimate, don't forget to include time spent waiting for answers or verification from other stakeholders. If you're integrating with a third-party service, include time for back-and-forths with tech support, and for implementing workarounds because their platform doesn't actually do what it says it does the way it says it does, and (if they're a new vendor) for contract negotiations to drag on.

Then multiply your estimate by two.