Analysis of monthly code output by my users-* o *

WriteCodeIt has been several years. speaking of the ability to write code, I am afraid there will not be a lot of people beyond me. however, after all, leaders are leaders. Have they ever learned management or tried to use pipeline theory to lead software development leaders. moreover, such leaders are not uncommon in China. the common cause of these leaders is that the target product is to be completed by the deadline, and all things can be quantified by hand, while staffing "meets the development progress as normal ". under this premise, various variants will appear.

Some do not clearly define the function list; some do not have the ability to know where the obstacles may be encountered in development; some do not know the true capabilities of team members ;...; more importantly, it is a great achievement. sometimes, I am also a member.

Here, let's talk about the Mythical man-month. All our progress is measured by the man-month code output. Increasing "man" cannot shorten the "month.

The amount of code that a target product can have is roughly no different from the budget. in this case, I have some leader with inaccurate estimation of the amount of code. we usually break down the amount of code into every module, and accordingProgramStaff's ability to allocate Progress requirements. in many cases, when the progress is unbalanced, the first response is to increase manpower. but in fact less than 10% of projects with increased manpower can be solved on time. in many cases, the added personnel cannot really enter the work, because the module can no longer be subdivided into small pieces to add new personnel. or the end time of the project has been reached when new users are familiar with the existing code structure.

The monthly code output is not a fixed value. My maximum writing time can reach 1600 rows/day. Is it actually 32000 rows/month? No! The code output at more times is between-rows/day. There are also manyAlgorithmIt takes one day. only 100 rows/day. based on the situation in the past three years, 5000 rows/month are relatively objective. this is the speed of C/C ++. it's my speed. Do other programmers have such efficiency? It is rare to actually exceed. even such code efficiency is not suitable for considering the progress of computing into commercial products. (Personal perfect products and commercial perfect products will be written in the future when there is a desire for writing.) many difficulties are not solved by reducing the monthly code output.

At present, I am more inclined to allocate time, which is also a more realistic time allocation, with no difficult time allocation.

20% code editing

30% debug

30% documentation

20% retention time.

This means that even if there are no known difficulties. it is still necessary to retain 20% of the time. it is very likely that a small mathematical logic will keep you busy for a day. this is not caused by carelessness. and no one can avoid negligence. in contrast, 30% documents sometimes cannot complete beautiful documents.

After learning about this myth, we can take the initiative.

1. first, do not underestimate the difficulty of any product. It is always correct to estimate the difficulty. (I have made such a mistake many times.) in this way, I want to spend more time before determining the task progress.

2. Obviously, since problems may occur at any time, why not do more work in advance? Few would like this. however, in my experience, I must do more in advance. in the last two projects, most of the work was completed many times in advance. 90% of things are finished, and the product delivery time is one month left. it was easy to see, but still busy solving the last difficulty. The task was completed on the last day. very risky. programmers who finish their tasks according to the schedule will surely make a jump. believe it! Hum, look for one. I'm confident in this judgment.

<Man-month myth> a good programmer may be 10 times more efficient than a bad programmer. in my Mythical man-month, there are indeed examples of a good programmer who is 10 times faster than a bad programmer. at that time, the team could not complete a programmer with extremely simple functions in one day. (I don't know how this person is now.) but in the theory of man-month, such people will still occupy the schedule...

Http://sdd.ttcone.com/lu0/web/tips/20030305.html (Sorry, no source and author found)