design – Guidelines in determining the timing of development and refactoring of web projects


The task was to support the site, which was written for many years and is a fierce shit code. No documentation, no comments. The author has not heard of formatting. But there is a keen desire of the site owners to make patches where, in their opinion , the most problematic places.

In the near future, there will be a conversation about the timing of work and I would like to start not from compromises (like this: I think it will take me six months only for the minimum necessary revision of the code, the customer thinks that everything needs to be done in a week => agreed for three months ), but from objective guidelines .

An example for a seed (conventional numbers). The total amount of code is 50 thousand lines of code. I can write 50 lines of normal, test-covered and documented code per day. Hence, we have 50,000/50 = 1000 workdays = 200 weeks = 3 years 10 months of work of one programmer (excluding vacations and holidays).

I would like to hear about such objective guidelines in assessing the time of analysis / refactoring / creation of a web application . Well, the logic of the assessment will also be extremely interesting.


If the answer is interesting purely theoretically, there is such a metric as cyclomatic complexity that can be measured. Most likely there are some more.

I also saw an article on Habré with reflections on this topic.

Scroll to Top