How do programmers estimate their project development time?


The estimation of project time is very important to the success or failure of the project. Project time management includes all processes required to complete the project on time. However, in the actual project, the project is often delayed and the estimation is seriously inaccurate.

Estimating the time itself is difficult. Every programmer’s estimate will fall short of the time it really takes. The estimated time is short, indicating that some things have been ignored (compiling, testing, submitting code). The estimated time is too long, which means the task is too big to understand.

For junior programmers, this estimation error is chaotic. They often despise some tasks and overestimate some slightly difficult tasks. I think for an experienced programmer, the time of a task should be between half an hour and 24 hours, and tasks beyond 24 hours need to be split. When programmers think about it, they may think it will take 60 hours, but in fact, even experienced programmers need to divide tasks into controllable modules to analyze and make decisions.

Another important thing to realize is that experience in programming is not equal to experience in time estimation. A programmer who has never done duration estimation is not good at estimating time. If you don’t compare the time you really need with the estimated time, you can’t get the experience of correctly estimating time from other feedback information.

Every programmer uses evaluation techniques. In order to improve this skill, you can exercise on every task you undertake. At the beginning of the task, estimate the time required for development and compare it with the time you actually spend in the end. In this way, you will not only improve your understanding of the details of the task, but also improve your time estimation skills.

Hofstadter’s Law: the actual time is always longer than expected, even if you consider Hofstadter’s law.

PM often complains that why the company’s development can never estimate its own project time?! However, smart programmers have long been used to this. I’ve even seen a project that is expected to be completed in two days and takes four months. Even according to the rule of thumb of “doubling time”, it’s quite exaggerated. At a high level, the problem is that engineers and PMS or others have different methods and ways of thinking about time estimation.

The first reaction of most engineers is the shortest time it takes to write a prototype if everything goes according to plan. What the PM or other downstream personnel want to know is when the project can be prepared and how long is the period from this time to release? So these are two completely different stories.

Therefore, for engineers, mastering time estimation is a necessary skill, which means that you are a professional, stable and efficient developer.

Why time estimation is needed?

External dependency

Nothing that works will happen out of thin air. Projects usually have external dependencies, such as communication with functional teams (finance, PR, customer support) and customer communication. The coordination with these external dependencies is often the work of PM or CEO, which means that the person (Engineer) who is most qualified to make time estimation is not the person who needs to do these calculations most. This asymmetry leads to fundamental tension.


Time measurement is also critical to determining priorities. Cost performance is an important indicator in the engineering field. Even if the function you are doing is the most powerful in the world and it takes a long time to realize after time calculation, the priority of this function will not be too high.

For example, you are working on a project that can make the website 50% faster, but you could have completed two projects in the same time, and each project can make the website 40% faster. If you don’t spend some time on preliminary calculation, you never know you can make a faster website!

Primary time estimation

Assuming that we have reached a consensus that time estimation is very important, let’s continue to see how to estimate. Usually, we underestimate the time required because we think “how long does it take to write a prototype?”.

However, the delivery is often much more than the prototype, and you also need to consider the time spent on testing, debugging and optimization. There are meetings, interviews, code reviews, and even emails that take time.

Another reason for underestimating the time required is unexpected problems, which can not be fully considered, such as ide update, which makes you spend an extra day configuring the environment, etc.

Based on this, we’d better not trust the so-called experience and intuition.

Step 1: develop technical proposal

Before starting any important project, you should have a technical plan or design document. The purpose of this document is to let others know what you are doing and get feedback. When you pay attention to the technical details, you will know more clearly the specific time spent. For example, updating a library to a new version may take an extra day. You even have to write a library yourself.

Particle size is very important here. If there is any part that makes people feel unclear, either you should know more about it, or you have to break it down into more detailed steps. At the same time, if one step is too detailed, it may be too fragile and lead to the invalidity of the whole plan, so we should grasp this degree.

To know what should be considered in your document, check out Alicia Chen’s article. The key is to communicate clearly with PM and eliminate ambiguities, so as not to overturn and start again in the end.

Step 2: add a time estimate for each step

How long does it take to implement each step in the document, which often involves the study of details (does this have a library?). Therefore, depending on the nature of the project, a simple prototype can help reveal many potential pain points.

Step 3: add fault tolerance time

Now you have a preliminary time estimate, but there are many other factors to consider.

Debugging at any time: bugs are difficult to avoid, which depends on the developer’s experience in a specific code base and the maturity of the code base. Meetings and holidays: Generally speaking, you don’t knock the code during meetings or holidays, so how long does it take to actually knock the code? So take a good look at the schedule when estimating time. Final testing: you should usually test while coding, but many teams still need to do integration testing before release, so leave this part of the time in your estimation. Code review: how many rounds do you usually need in this code base? How long does each round take? How many reviewers do you have to go through? Pay attention to the reviewer’s schedule to ensure the time of code review.

When you take into account the cost of delivery time, you can see that your time estimate matches the actual release time of the project much better. Although the actual situation may be longer, you may also need to shorten the construction period due to pressure. But when people understand that your estimate is more accurate, they will trust you more.

Step 4: Post release review time estimation of the previous period

It’s painful to resume, but looking back can make you do better next time. What happens to every project whose actual time does not match the expected time, find the reason and improve it.

In a word, everything lies in communication. Communicate in advance and often to understand each other’s schedule and demand changes.

Communication with relevant participants such as PM can also enable the other party to provide important information that may affect your estimation. A designer may say that this animation needs a week’s construction period, so it’s simply cut off. Another PM may also add that the prototype is only for users, and this iteration does not need to deal with too many bugs.

For engineers, do not make unrealistic compromises with shorter construction period, and be open and more professional. For PM and others, it may take a process to respect this estimate, but you should know that nagging alone cannot shorten the construction period.

It is not easy to estimate the project time. Only be good at communication, empathy and determine the functional priority.

Read more

To a foreign company? Why are other programmers so easy

One move teaches you to create a sliding visual effect

NDK project practice – unloading and monitoring of high imitation 360 mobile assistant

(Android) interview question level answer (selected version)

Believe in yourself, there is nothing you can’t do, only what you can’t think of