How do programmers estimate their project development time?

The estimation of project time is crucial to the success or failure of the project. Project time management includes the various processes required to complete the project on time. However, in actual projects, project delays often occur and estimates are seriously inaccurate.

Estimating time itself is difficult. Every programmer's estimate will be slightly different from the actual time required. The estimated time is short, indicating that some things have been ignored (compiling, testing, submitting code). It is estimated that the time exceeded indicates that the task is too large and difficult to understand.

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

Another important thing to realize is that experience in programming is not the same as experience in time estimation. A programmer who has never done a duration estimate will not be good at estimating time. Without comparing the actual time required with the estimated time, you won't be able to get the experience of correctly estimating time from other feedback information.

Every programmer uses evaluation techniques. To improve this skill of yours, you can practice on every task you take on. Make an estimate of how long development will take at the beginning of the task and compare it with how long it actually takes you in the end. In this way, you not only improve your understanding of the details of the task, but also improve your time estimation skills.

Hofstadter's Law: It always takes longer than expected, even if you take Hofstadter's Law into account.

PMs often complain, why the company’s developers can never estimate their own project time? ! However, astute programmers have long been accustomed to this. I've even seen a project that was expected to be completed in 2 days end up taking 4 months, which is quite exaggerated even according to the "double the time" rule of thumb. At a high level, the problem is – Engineers and PMs or other people have different approaches and ways of thinking about time estimation.

The first reaction of most engineers is the minimum amount of time it would take to write a prototype if everything goes according to plan. What the PM or other downstream personnel want to know is when the project will be ready, and how long will it be from this time to release? So these are two different stories entirely.

So for engineers, mastering time estimation is an essential skill, which means you are a professional, stable and efficient developer.

Why is time estimation needed?

External dependencies

Nothing valid happens in a vacuum. Projects usually have external dependencies, such as communication with functional teams (finance, PR, customer support) and communication with customers. Coordinating these external dependencies is often the job of the PM or CEO, which means that the people most qualified to make time estimates (engineers) are not the people who most need to make these estimates. This asymmetry creates fundamental tensions.

Priority

Time measurement is also critical in determining priorities. Cost-effectiveness is an important indicator in the engineering field. Even if the function you are working on is the most powerful in the world, if time calculation shows that it will take a long time to implement, then the priority of this function will not be too high.

For example, you are working on a project that will make the website 50% faster after completion, but you could have completed 2 projects in the same time, and each project could make the website 40% faster. If you don't take the time to do preliminary calculations, you'll never know where you can build a faster website!

Primary Time Estimation

Assuming that we have reached a consensus that time estimation is very important, then let’s continue to look at how to estimate. Often we underestimate how long it will take because we think “how long does it take to write a prototype?”

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

Another reason for underestimating the time required is unexpected problems that are often not fully considered, such as IDE updates that cost you an extra day to configure the environment, etc.

Based on this, it is best not to believe too much in so-called experience and intuition.

Step 1：Develop technical plan

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 to get feedback. When you notice the technical details, you will have a clearer idea of ​​the specific time spent. For example, updating a certain library to a new version may take an extra day. You even have to write a library yourself.

Granularity is very important here. If something feels unclear, either you should know more about it or break it down into more detailed steps. At the same time, if one step is too detailed, it may be too fragile and the entire plan will be ineffective, so you must grasp this degree.

If you want to know what you should consider in your document, you can read this article by AliciaChen. The key is to communicate clearly with the PM and eliminate any ambiguities, so as not to have to overturn and start over again in the end.

Step 2: Add time estimates for each step

How long does it take to implement each step in the document? This often involves studying the details (is there a library for this already?). So depending on the nature of the project, doing a simple prototype first can help reveal many potential pain points.

Step 3：Add fault tolerance time

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

Debug on the go: Bugs are inevitable and depend on the developer's experience with a particular codebase and the maturity of the codebase. Meetings and holidays: Generally speaking, you don’t code during meetings or holidays, so how long does it take to actually code? Therefore, take a good look at the schedule when estimating time. Final testing: You should usually test as you code, but many teams also need to do integration testing before releasing, so allow for this part of the time in your estimate. Code Review: How many rounds do you typically do in this codebase? How long does each round take? How many reviewers does it have to go through? Pay attention to the reviewer's schedule to ensure time for code reviews.

When you factor in the cost of delivery time, you can see that your time estimate matches the actual release time of the project much better. Although it may actually be longer, you may be pressured into shortening the schedule. But when people understand that your estimates are more accurate, they will trust you more.

Step 4：Estimation of review time after release

It’s quite painful to review Yes, but reviewing allows you to do better next time. What happened on every project where actual didn't match expected time, find the reason and improve it.

In short it’s all about communication. Communicate in advance and frequently to understand each other’s schedules and changes in needs.

Communicating with relevant participants such as the PM can also allow the other party to provide important information that may affect your estimate. A designer might say that the animation will take a week to complete and should be cut. Another PM might also add that this prototype is just for user research and that this iteration doesn’t have to deal with too many bugs.

For engineers, don’t make unrealistic compromises of shorter construction periods. Being open and honest is more professional. It may be a process for PMs and others to respect this estimate, but know that you won't shorten the schedule by nagging.

Project time estimation is not easy, only good communication, empathy and prioritization of features can do it.