But programmers who have experience in developing commercial projects have encountered various situations in terms of development time estimation, the most common of which is that the actual development time is always much more than the estimate.

Many people can’t say why this is the case, but this article will take you to explore what factors affect development time estimates!

As an individual software engineer, you often don’t have enough background, education, or experience to determine the timeline, so you should talk to the project manager, explain to them what needs to be considered in the timeline (not just the time it takes to write code), and then build a method of estimating time.

How you estimate your development time depends on the size of the project you’re working on, such as a small, medium-sized, large-scale project, or just part of a project.

By definition, a small project is a project that software engineers can complete individually. The main impact on the progress of the project is the competence and productivity of this software engineer.

Estimating the development time of a small project is much easier and more accurate than estimating a large project. Small projects don’t involve parallel development, and only the productivity of individual developers needs to be considered on the schedule.

There is no doubt that the first step in estimating the development time of a small project is to identify and understand all the work that needs to be done. If some parts of the project are not clearly defined at this point, considerable errors will be introduced into the schedule, because these undefined components will inevitably take a lot more time than you think.

When estimating when a project will complete, the design documentation is the most important part of the project. Without a detailed design, it is impossible to know which subtasks the project consists of and how much time each subtask will take to complete. Once you’ve broken down your project into appropriately sized subtasks (a suitable size is a clear idea of how much time it will take to complete it), all you need to do is summarize the time of all the subtasks to produce a reasonable preliminary estimate.

However, one of the biggest mistakes people make most often when estimating the progress of small projects is that they add time to the schedule of subtasks and forget the time of meetings, phone calls, emails, and other administrative tasks.

It’s also easy for them to forget to increase testing time, as well as time to find and fix defects (and retest).

Because it is difficult to estimate how many defects exist in the software and how much time it will take to resolve them, most managers will increase the first estimate in the schedule by a factor of 2 to 4.

Assuming that a programmer (or team) can maintain reasonable productivity on a project, this formula can be used well to estimate the development time of a small project.

Conceptually, medium-sized and large-scale projects are made up of many small projects (assigned to individual team members) that combine to form the end result.

Therefore, the first way to estimate the progress of a large project is to break it down into a bunch of smaller projects, then estimate the development progress of each subproject, and then merge (summarize) it together for an overall estimate.

This is an enlarged version of the estimated progress of small projects.

Unfortunately, in reality, this way of estimating can cause many problems.

The first problem is that medium-sized projects and large projects have problems that are not present in small projects.

A small project usually has only one engineer, and as mentioned earlier, the timing of a small project depends entirely on the productivity and time available to that engineer.

In a larger project, many people, including people other than engineers, can influence the estimation of progress. A software engineer with critical knowledge may be on vacation or sick for a few days, delaying another engineer from getting the information he needs to get the work done.

Engineers working on large project development typically have several meetings per week (which are not mentioned in most schedules) that keep them offline for several hours, that is, during this time they are not programming.

In large projects, team composition can also change, for example, some experienced programmers leave while others have to continue learning other subtasks, and new programmers who join the project need time to keep up.

Sometimes, even equipping a new employee with a computer workstation can take weeks (for example, in the IT department of a very bureaucratic large company).

Waiting to purchase software tools, development hardware, and support from other parts of the organization can also cause scheduling failures.

The list goes on and on. Few progress estimates can accurately predict how much time these will take.

Ultimately, estimating the progress of medium-sized and large projects will include 4 tasks, that is, breaking down the project into multiple smaller projects, estimating the progress of these small projects, increasing the time for integration testing and debugging (that is, the time it takes for each small project to be combined and working properly), and then getting the final summary result by a multiplier factor.

This approach was not precise, but it still works today.

Because project schedule estimates involve predictions of the development team’s future capabilities, few people believe that the planned schedule is completely accurate.

However, common software development progress predictions are particularly bad, for a number of reasons:

They are in R&D projects. R&D projects include doing things you’ve never done before. They require a research phase during which the development team needs to analyze the problem and try to determine a solution. Often, there is no way to predict how long the research phase will take.

Management has set a timeline in advance. Typically, the marketing department decides that it wants to sell the product before a certain date, and the management department formulates the project plan by pushing back the time from that date. Before asking the development team to estimate the timing of subtasks, management already had some preconceived notions about how long each task should take.

This team has done something similar before. Management usually thinks that if you’ve done something before, it’s easier to do it a second time (and therefore less time). In some cases, this makes sense. If the team is working on the same R&D project, it will be easier to do it a second time, because they only need to do the development and can skip (at least most) the research phase. However, the assumption that it is always easier to do a second time is rarely true.

Not enough time and money. In many cases, managers will set some kind of funding or time limit if the project must be completed, otherwise the project will be canceled. For those whose salary is tied to the progress of the project, this is wrong. If they are asked to choose between saying “yes, we can fit the plan” and finding a new job, most people will choose the former, even if they know the odds are slim.

Programmers will exaggerate their efficiency. Sometimes, when software engineers are asked if they can complete a project in a certain amount of time, they don’t lie about how long it will take, but rather make optimistic estimates of their performance, but in reality they rarely stand up for themselves at work. When asked how much effective work they can generate, most software engineers will give a chart showing the largest output they have ever produced in a short period of time (e.g., 60 to 70 hours a week in “crisis mode”), but they rarely consider unexpected difficulties (e.g., a very serious system defect).

The progress depends on the extra time. Management (and some engineers) often assume that when progress starts to be delayed, programmers can always put in “a few hours” more to catch up. As a result, progress tends to be more delayed than they expect (because they ignore the negative effects of heavy overtime from engineers).

Engineers are like building blocks. A common problem in project scheduling is that management believes that software can be released early by increasing the number of programmers in the project. However, as mentioned earlier, this is not necessarily true. You can’t expect the progress of a project to change by increasing or decreasing the number of engineers in a project.

Estimates of subprojects are inaccurate. The actual project schedule is developed in a top-down manner. The entire project is divided into several smaller subprojects, which in turn are divided into several subprojects, and so on, until the size of the subprojects is so small that someone can accurately predict the time it will take for each subproject. However, this approach presents three challenges:

Whether you are willing to do your best to schedule in this way (i.e. provide a correct, accurate top-down analysis of the project).

Accurate estimates of small subprojects (especially software engineers, who may not have proper management training, so it’s not clear which factors are to be considered when estimating progress).

Whether you are willing to accept the results of the schedule estimate.

This article is excerpted from the book The Way to Programming Excellence (Volume 3): Software Engineering!

Want to learn how to better develop your software and excel?

Welcome to this book!

▊ The Way to Programming Excellence (Volume 3): Software Engineering”

By Randall Hyde

Zhang Ruofei translated

Comparable to Gartner TAOCP’s Classic Series in the field of programming

What 100 books don’t make clear is explained clearly by this book

The machine principle → the underlying language→ high-level code → team productivity

This book provides an in-depth look at everything from development methods and productivity to object-oriented design requirements and system documentation.

Through this book, you will learn: why following the software craftsman model allows you to do your best; How to use traceability to enhance document consistency; How to create your own UML requirements through use case analysis; How to develop better software using IEEE documentation standards.

Through an in-depth explanation of the skills, attitudes, and ethics aspects of high-quality software development, this book reveals the right way to apply engineering principles to programming. In the process, Hyde will not only teach you the rules, but also tell you when to break them. Not only will he inspire you to know what best practices are, but he will also let you discover best practices that are right for you. With tons of resources and examples, this book is the best guide to code that will set you apart from your peers.

(Limited time order minus 50, quickly scan the code to buy it!) )

Book Delivery Rules:

This benefit will give away the “Ways to Programming Excellence (Volume 3): Software Engineering”* 5 copies

All you need to do is click on the card below, follow the official account, and send the keyword: 20220929 to participate in the lottery.