Believe that everyone has to deal with a short development time to assess the situation, if is a personal project is also good, late is late, but in a more collaborative team, developing complete time delay is very bad, always little aspects will affect their credit (always can’t finish it on time commitment), big field will cause the project delivery time delay, Influence colleagues’ schedules for the next link. So I’ve summarized some of the reasons why development time estimates are biased. Because I work in a small team, some of my experience may not be suitable for teams of more than ten people.

The root cause of the miscalculation

First, we must recognize a structural reason for the inaccuracy of estimating development times: it is impossible to predict all the implementation details in advance, so there is a bias. For example, if we know that it’s 40km from point A to point B, and we know that our speed is 10km/h, can we estimate how long it takes to get from point A to point B? Of course you can. Anyone can do that. So analogously to software development, if we know the total number of lines of code required for a release, then we can calculate how many lines of code we can write in a day to get an accurate time.

What’s the problem with this solution?

First of all, we don’t necessarily know where we’re going. Maybe the needs change as they go along.Suppose we have a defined requirement, but there is not just one way to implement it. There are many ways to implement it: Even if you do know how to implement it, you can still miscalculate the speed of implementation because many programmers are overconfident.In general, the programmer does not know enough about the implementation details of the project at the beginning of the project (it is almost impossible to come across requirements that have been done exactly the same before) to make a reasonable estimate. But as you do more research on how to do that, the margin of error Narrows. After you start coding, it shrinks again. It is a mistake to ask the programmer to make an accurate estimate at the peak of the deviation before the project begins, and then not revise it.

Agile development does not solve this problem

The traditional development mode has a long development cycle and a large deviation in the final development time. Agile has shortened each development cycle so that there is less deviation time per cycle in absolute terms, but it does not actually solve the problem of development time estimation bias.

Another option is to make the development cycle date-driven, setting a date and then ending development at that date. Develop higher-priority features in each iteration so that each release is the most valuable. This strategy is a bit more advanced and relieves programmer baldness because it eliminates the issue of estimating development time.

But escape, while useful, does not always succeed. There will still be feature-driven versions. For example, the boss may suddenly say to you, we need to add a live streaming feature, you can tell me when it is finished online. I don’t think you’re going to say I’ll tell you when I’m done.

Understand the business scenario behind the requirements

The first step is to clarify the requirements. A lot of people get the demand buried in the beginning to do, after finishing and product managers want different, time is certainly delayed the most. Product managers tend to focus on processes, interactions, and have a poor understanding of the performance of technical solutions. So if there is no clear communication between the two sides, the expectations of the two sides may be inconsistent. For example, a set of user Settings saved to the server, whether to real-time automatic saving, or users manually click save before saving. Do YOU want to save only one copy or maybe many copies? Do you want to delete? Ultimately, it can affect the estimated development time.

This part first needs to be developed to understand the business scenario behind the requirements so that we know what the real problem is that the technology is trying to solve. What the product really wants is for us to solve a business problem, not for us to have a button at the end. Once we understand the business scenario, we can derive the requirements for the technical metrics, which we then confirm with the product manager. After confirming the technical requirements, also confirmed the technical implementation plan. This communication can avoid the product manager saying that this requirement is very simple and why it needs to be done in 3 days. Because we will tell him where the shortcomings of the 3-day implementation are and whether he can accept the technical indicators.

Document requirements changes during development

I strongly recommend introducing requirements change statistics into the R&D process. The variable that has the greatest impact on development time is the change in requirements. Requirements come and go, and developers spend two or three times as much time implementing one requirement. It is not necessarily the developer’s fault that the delivery time is delayed. If there is no record of this, the team may end up simply assuming that the developer is slow, or that the development time estimate is badly wrong.

If you want to record requirements change statistics, you first need to have a clear list of requirements. The developer needs to break down the product manager’s requirements into a list of R&D requirements. The functional description of each R&D requirement should be confirmed with the product and test teams prior to the start of the iteration. Since my team uses GitLab to manage code, each iteration is broken up into issues.

After entering r&d, if the requirement is not in the description of r&d requirement, a requirement change is counted. Whether a requirement misses a process or the design is changed, the change record should be updated under the corresponding R&D requirement issue. After the final release is delivered, the development time impact due to requirements changes can be calculated.

Communication efficiency in development

If it’s team development, consider team communication. It is rare to receive a request and complete it without delay. You may need to communicate the interaction details with the product, such as asking what to do if something fails here. You may need to communicate with the design about the specific effect of this dynamic effect, whether it disappears after 200 milliseconds or 300 milliseconds. It may also communicate to the back end what values should be passed to the interface’s parameters. Or after a stage of development you may need to demonstrate to other members. All of this interteam communication takes place during development. So development time is not just time to write code. When estimating development time, take into account the time spent communicating with each functional team.

Development path dependency

If a release takes 3 days to design, 3 days to develop the front end, and 3 days to develop the back-end interface, can 3 people develop it in 3 days at the same time? Anyone who has had development experience knows that these three tasks cannot be carried out completely in parallel. Is it true that after 3 days of design, the front end can be developed according to the UI? Not necessarily.

Everything doesn’t always work perfectly. After the completion of the design drawings to the development may need to communicate modification. There is also such a risk that the back-end interface is delivered to the front end. Although the interface documents on both sides are well defined, if a module has many states, there may be some problems when accessing the interface. After all, the backend does not guarantee that interface development will achieve perfect quality once and for all. If the front end relies on the interface integrity of the back end, then progress is delayed.

Therefore, path dependence should be taken into account when estimating development time. If there is no design review in the development process, consider that the design may be modified after completion. The back-end interface, while developed, does not always work as expected. For example, the back end plans to connect the interface to the test environment in three days, and the front end estimates the interface debugging time in half a day or one day.

Don’t forget that code is also architectural

I think architectural design is the most overlooked time for programmers to estimate time.

Too many scenarios where confident programmers evaluate development time are where there is so much code to write that I start typing quickly to see how long it will take. Especially a complex function, module, responsibility division design is to need a lot of time. I would rather spend a few more hours implementing the design in the early stage, rather than start all over again in the middle of writing to find that the scalability is poor.

Just because the code is functional doesn’t mean the job is done. Programmers who are concerned with quality need to review the code: readability, naming, responsibility division, future extensibility, and so on. It’s always best to examine whether you need to refactor as soon as you’ve written it, and wait until problems arise to refactor, which takes more time to understand the context.

If you give yourself two days, that’s two days of feature development. At this time, you suddenly have a strong hunch that I can optimize the code, but I don’t want to delay the completion of the project, so let’s do it now. A technical debt is thus created.

Another problem with architectural design is the API calls for individual modules. Collaboration among several people in a release is usually divided by module functionality. It’s possible that two people develop a component on their own, and when they connect, one of them doesn’t have the right API. I have to say that this is a very common problem, and even experienced programmers can’t guarantee that the API is designed to make perfect sense for the business side. But when estimating development time, we often overlook how long it takes to tweak the API when the two modules are finally merged together. So your development time is estimated to be less.

In order to improve the accuracy of this part of time estimation, I will conduct interface design communication within the R&D team before the estimation of development time. The interface design that defines the flow of data is discussed and validated by all members of the team. Once the API between each module, the responsibility division of the class, and the data structure are defined, it will take less time for everyone to develop their own design parts.

For code quality problems, if there is a code review in the R&D process, the time when the code needs to be modified due to the code review must be included. The advice here is to validate the design of core, complex classes together before they are developed, to avoid finding out during review that the design of the code is completely broken and needs to be rewritten. In fact, it is enough to define the exposed interface.

Compatibility with older code

Self-development time estimates are generally manageable, but if your code is built on ancestral code, time estimates are completely inaccurate.

The requirements of a program are constantly changing, and if earlier code does not provide extension points for new requirements, at worst it may need to be rewritten. In the good case, it was already designed to be extensible, allowing new functionality to be plugged in with just a few lines of code.

Therefore, when estimating development time, it is important to distinguish which requirements need to be changed on older code. Especially if you’re not familiar with the original implementation, you’re basically making up a number. So in this section it is important to know the original implementation details in advance and estimate the development time after you have a rough idea of how it will be implemented.

Don’t forget there’s time to test yourself

Some module tests are more time-consuming, if there is such a demand for development time but also the time to estimate the self-test. If you hand it over without testing yourself, the testing raises a lot of bugs and ends up wasting more people’s time.

conclusion

The root cause of bad time estimates is that you miss a lot of the time needed in the development process. There are also some things you don’t acknowledge when making estimates (architectural design, time to modify old code, for example). Add all of the points mentioned above to your development time, and you’ll get less and less time off as you get more experience.