Price change: how much will it actually rework the code

Original author: Doug Bradbury
  • Transfer
The author of this material shares the way to estimate the time that will be spent on rewriting an already implemented project.

As the code grows, it becomes more difficult to work with it. Years of development and catching bugs lead to the desire to cross out everything and start from scratch. Indeed, the idea of ​​leaving mistakes in the past, arming with new technologies and doing everything right this time is very tempting. However, before jumping into the abyss, I still suggest taking a closer look at the real value of this step.

Scoping Model

You can put all the features of your application in one list, and then evaluate the stages and the approximate time of their processing. Most do just that before getting started. But why then, in practice, it turns out that such projects take 4, 8 or even 10 times more time than the developers laid at the start?

Read also
The publication of the time spent on writing software code, which is useful in assessing the scope of work: "Rule 10: 1 in programming and writing"

There are three key factors that significantly stretch the process. And usually they are ignored when estimating costs. This is about:

  1. the need to make up the difference between the levels of current and new applications,
  2. the amount of unintended changes
  3. improvements that will have to be made so that users want to switch to a new application.

Reduction of difference

The first factor is that the new application needs to catch up with the current one.Suppose we are talking about replacing the used software system (and this is almost always the case, because why change something that no one uses). Substantial efforts are expended on maintaining its work: users make inquiries, bugs emerge, types of sales appear for which new functions have to be introduced. In most cases, the team can not throw the development of the current system to take on the creation of another.

When you decide to re-develop the application, you estimate the cost of this project only on the basis of the accumulated knowledge of the current system. At the same time, it is impossible to take into account in advance those features that will be added to the current version of the system simultaneously with the development of a new product, since at the time of the assessment there was no need for these functions.

Nevertheless, it is possible to make a guess by comparing the productivity of the old and the new teams. For example, if a new development team issues features twice as fast, then the predicted time frame for reducing the gap between projects must be multiplied by two. If they work five times faster, the multiplier will be 1.25. The table below shows the time it takes the new team to catch up with the old one at different speeds.

Unintended amendments

The next factor extending the project processing deadlines is the unobvious changes hidden within the existing application. As a rule, quite old systems are subjected to processing. Over the years, many functions have been implemented in them, a lot of bugs have been fixed. And often projects are experiencing more than one group of developers. As people leave the team, their features are forgotten or misinterpreted. But while features work, they are claimed by at least some clients.

If you do not take into account this factor and release the release, then it will turn out to be worse than the norm (according to the schedule above). Although everything planned will be implemented in it, the possibilities of a new project will still lag behind the old application. And you will probably have to enter the missing features.

This additional amount of work is overlooked during the preliminary assessment. It is quite difficult to determine, but at least you can make appropriate assumptions based on how much the new team revealed during the study of the current product. It is best to measure this indicator as a percentage of the known projected amount of work and add to the final formula. We denote this factor by Fnp .

Improvements required for implementation

The last obstacle faced by products that catch up with their predecessors on features is the fear of users to switch to another system. If there is no fundamental improvement in the novelty, what is the point for the end user to move to it? This is especially true when the current software is tightly integrated with the business processes of another organization. No matter how cumbersome the old system was, people had become accustomed to it, learned to bypass the inconvenience, and developed an appropriate “muscle memory”. Offer them to just throw all this experience in the trash and start over? This does not convince users to evaluate the novelty.

Therefore, even if the team takes into account all known and unknown features, they will have to invent and add new functions until the product looks convincing enough in the eyes of existing users.

Quantifying the impact of this factor is also quite difficult. But you can include an assumption in the formula as a percentage of the known projected amount of work. We denote this factor Fy .


The sum of three factors - reducing the difference Fср , unforeseen amendments Fnp and improvements to the project Fu - many times increases the preliminary estimate of the time and cost of development. The

total period, expressed in relation to the initial estimate, can be calculated by the formula Total time costs = To + (Fср * To) + (Fnp * To) + (Fу * To)

Consider an example. Suppose you put together a team to estimate the cost of processing your main product. They assumed that four developers would do it in one year. This assumption is written as T0 = ​​1 .

Now suppose that developers are stamping features three times faster than the old product team. PH = 3. Hence, the factor of reducing the difference will be 3 / (3 - 1) = 1.5 .

Thus, the project has already added 50% or six months, simply on the basis of the time it takes the new team to catch up with the old one.

What about unanticipated amendments? How can you express all that unknown, which is hidden in the old application, as a percentage of the total feature volume? To do this, you can consider how many years the application has been developing and complementing, and how many times the team has changed. Let's try to guess: Fnp = 25% .

Now we estimate what it would take for existing customers to accept the product. What requests for new chips have accumulated in your backlog? Which of them are valuable enough to convince existing customers to switch to a new product? Remember that attempts to impose a transition on a client sometimes end in that it is easier for him to go to a competitor. For example, we predict Fy 30%, and this will be enough for implementation.

Total = 1 + 0.5 + 0.25 + 0.3 = 2.05 years.

Even with the rather modest assumptions, the initial forecast more than doubled. Fср , the indicator of the reduction of the difference - the most volatile factor. And if the new team will cope only twice as fast? Then the initial assessment of this factor will double, and the final result will grow to 2.55!

Before analyzing the benefits of a new application and the cost of reworking it, it makes sense to calculate the real costs of such a project. I suppose in most cases you will come to the conclusion that such an approach to processing will almost never pay for itself.

Is there a better way? I will offer an alternative in my next post.


Also popular now: