Does the amount of code per day really matter?

Turn an article for you to see ...

A project manager who worked in the US for 2 years and worked in an Indian company for 4 years had a conversation with our senior Software development manager.
The Print manager asked, "How many lines of code do you produce each month?" "
Our manager weighed on for a long time and said modestly, "The per capita code is more than 10,000 lines, less than 20,000 lines."
After the printing manager listened, the eyes were round: "Oh!" You have gone far beyond the international level. "
Our manager replied nervously, "What about you?" "
The Print Manager replied very carefully: "Our company is currently efficient at 300 lines per month." "
This is a true story, and I would like to change someone else (including my old one) to give the same answer.
Why is there such a big gap with software powers?

First of all we have no concept of productivity. That's what most people do, 400 lines a day-500 lines of code are not a piece of cake. One months there are 30 days, so more than 10,000 lines a month is not easy to fix it?
As everyone knows, this great hypothesis has two fatal errors: first, no consideration of requirements analysis, summary design, detailed design, unit testing, integration testing, system testing time, and no consideration of documentation time, or even may not be aware of these processes.
This is not a joke, ask: do we have a demand analysis? Do we have a unit test? We have programming specifications, but have we complied?
Our code is colorful, the style is strange-
Don't we have "developed, haven't had the experience of designing documents"?

Don't we have the experience of "trying to turn the test, and everyone is starting to write documents"?
We are not someone who wrote in the document, "Does this software have no harm to humans and animals"?
Of course, we can not think of review time, the fundamental consideration of quality control?
We are most familiar with writing programs, system testing, maintenance, and others are superfluous. This is a typical small company guerrilla warfare practices, a person to engage in a small software, no process, no quality system, in addition to writing code, testing, nothing is necessary, very free, self-thought "bull not", it is easy, it is very simple, "management is wordy, the process is trouble", But the actual result is what we all know.
The second to first day can write 400-500 lines of code, does not mean that you can write 12000-15000 lines of code per month, the reason is very simple, a person 100 meters speed is 12 seconds, does not mean that his 3000 meters speed is 6 minutes. We are not robots, writing software needs to think, writing embedded software especially needs quality.
Indian engineers are human, Chinese software engineers are people, where can our code productivity and level be high? Just as everyone is mortal, you suddenly say you are faster than bullets, jumping 3 stories high.
Is this really the "ignorant" person "fearless"?
In fact, our productivity is very low, we do not feel it, many people do not believe that our public figures-monthly code only 120 line? If we count all the manpower, the time of all phases, we will not be surprised by this data. If you don't believe us, we'll take a product to calculate! Perhaps our manager himself does not know how much manpower has been invested in this product. Does Huawei have a professional software development management talent? At present there is almost no, perhaps we really have a monthly 20,000 line of programming experts, there are many self-thought can write 20,000 lines of code "bubble" master, but we do not have a real professional software talent!
At present, our company's sales are very good, selling very hot. But is this project development successful? No, perhaps more is the success of the market, as well as product pre-research project personnel success. How can it be successful to spend so much maintenance costs in the life cycle? If we build airplanes, we may not dare to sit on our own. What are the criteria and elements to measure the success of a project? A lot of people don't know. India's fastest-growing Infosys company tells us that the criteria for measuring the success of a project are "quality, cost and quot;" The key to achieving this goal is "process, technology, people".
When we make the plan, only the progress, may consider the cost, but has never considered the quality. Do we know the quality activities of project development? We don't know, do we know our quality goals? Neither do we; do we know how to control our quality? We didn't do it.
That's why we're not afraid, 100. But if we know that "fold" takes 1 million, will we be fearless in "100"? Look back at some of the industry standards: an Indian partner has passed the CMM5 level, and the joint development Project has a productivity of 400 lines per month. Among the coding stages, Indian engineers can write 200 to 900 lines of code per day.
During the 4-month joint development process –
In coding speed, our excellent engineers are similar to each other, but others have taught us how to ensure the consistency of code specification and programming style;
In terms of reading protocol standards, the other party's speed is 4-5 times our;
In the design aspect, the other side has the obvious superiority;
In quality control, we have no way to compare with them;
In terms of projections, the estimated workload of the other party is 36 months, our estimate is 22 people months, the actual number is 35 people months.
By contrast, my conclusion is that we are rich because we have a lot of bugs; we are fast because we do not have a quality system.
Some people think
Using the Configuration Tool SourceSafe, you will know what configuration management is;
Will draw Cantt Figure/pert Diagram, know the project plan is what is going on;
Fill in the form is the management;
To eat a meal is to communicate.
Without understanding the whole of quality, and not knowing why it is doing so, it is not surprising that there is such a huge gap in understanding that people can "understand", "speculate" and "know" others according to their own past experience.
At present, the company in the quality system training and implementation of the continuous strengthening, India's experience of the continuous promotion, in many aspects, such as process construction, forecasting, quality control, measurement system, we have a preliminary understanding of what to do. But we must continue to publicize, keep the soil, let all the people admit their ignorance, only in this way, we can from "ignorance" into "knowledge."
"The art of low-spirited", in the future, I do not want to listen to this bold rhetoric: "Our monthly code 10,000 line"!

Does the amount of code per day really matter?