Rules of Thumb for Software Development Estimations

The cycle is as follows: 1. Work on the task happens 2. New information comes to light 3. Estimations are improved and communicated 4. Go back to 1.

someone at the top needs to see if the company can invest that much money and for how long, which requires some numeric value attached to a project

Estimations create a shared understanding of the project size among team members and stakeholders.

Rule of thumb, 1.5x-2x your raw coding time estimation to get a good approximation of the real-time (incl. communication) you will spend on a task.

Estimations help you, as an engineering manager or startup founder, to maintain a semblance of sanity in the face of constant deadlines and deliverables. By knowing how long tasks should take, you can make informed decisions about priorities, allocate resources effectively

Resource Allocation: Estimations help prevent under- or over-commitment of resources.

But estimations serve a crucial purpose in the realm of software development. Without them, no software project would be green-lighted.

it's better to over-communicate than to expect people to communicate with you first

It's much better to tell someone, "Okay, after a week of exploration, we can say that the timeline is 12 months instead of the initial 24 months suggested." rather then "Ooops, the scope got huge and it's now 48 months instead of 24"

Don't forget to account for meetings, code reviews, and other non-coding activities that will inevitably eat into your team's time.

ensure your estimations have some buffer for the "human factor." I usually add 20-25% on top of the estimates

Of course, you can't account for thousands of unknowns, so the estimates should be on the safe side first and get shorter over time, not the other way around.