Performance management and internal consumption of software companies

Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/06/18/53660.html

Introduction: I saw a news article about Microsoft Vista on csdn today. The address is http://news.csdn.net/n/20060616/91704.html. The original text is as follows:

Microsoft manager revealed that the Vista delay was not implemented on the original date.
January June 16, MicrosoftProgramManager Philip Su said in a blog on Thursday that the next-generation operating system Windows Vista has been delayed for two reasons: first, the systemCodeIt is too complicated. Second, it is caused by Microsoft's corporate culture.
According to techweb, Philip Su has been in the Windows department for five years. He wrote in his blog that the Vista system code is complicated, and because of the enterprise culture, the company's Vista marketing date is not practical at all, so the delay of Vista is inevitable.
Su said that Vista has at least 50 independent "layers", and he only understood two of them during the five years. It is reported that Vista has 50 million lines of code. Generally, a Windows developer can write 1000 lines each year. Microsoft currently has 9000 developers around Vista. However, it can be calculated that it is still difficult to complete 50 million lines of code.
As originally planned, Windows Vista was supposed to be available in November this year. However, Microsoft announced in March this year that its vista enterprise edition will be available in November this year, and its personal edition will not be available until next January. In June 7, Windows Vista beta 2 entered the public beta stage.

I am most concerned about the above news: "generally, a Windows developer can write 1000 lines a year"
At first glance, Microsoft's employees are so leisurely at work. Write 1000 rows per year. Feel in doubt, hurry on Google's blogsearch, find the original one to see, found not so back, the original blog address: http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

let's see if, quantitatively, there's any truth to the perception that the Code velocity (net lines shipped per developer-year) of Windows has slowed, or is slow relative to the industry. vista is said to have over 50 million lines of code, whereas XP was said to have around und 40 million. there are about two thousand software developers in windows today. assuming there are 5 years between when XP shipped and when Vista ships, those quick on the draw with calculators will discover that, on average, the typical Windows developer has produced one thousand new lines of shipped code per year during Vista. only a thousand lines a year. (Yes, developers don't just write new code, they also fix old code. yes, some of those windows developers were partly busy shipping 64-bit XP. yes, because of them also worked on hotfixes. work with me here .)

Lest those of you who Wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year. so windows is in bad shape -- but only by a constant, not by an order of magn.pdf. and if it makes you feel any better, realize that the average US developer has fallen in kloc productivity since 1999, when they produced about 9000 lines a year. so windows isn' t alone in this.

Only in this way can people clearly understand what their blogs are saying, but the news is edited to attract attention.

But it reminds me of the internal management of software companies.
1. Performance management of software personnel.
I don't know how many companies still use the number of lines of code to calculate productivity. I think the only difference in this way is that the company cannot organize effective performance management. Performance appraisal should be evaluated by the following factors: technical complexity + time spent (ot time must be calculated) + weighted adjustment.
Business complexity often leads to technical implementation complexity. Engineers A and B complete different projects within the same time. The complexity of A is higher than that of B, so the performance of a should be higher than that of B. However, this is often not the case. Projects with higher complexity will require more time (if someone can finish it quickly, it indicates that his accumulated experience can be quickly analyzed or familiar with the business itself.) No matter how long it takes to complete the work, a reasonable assessment is required: 10 days, one month or more, it takes 1.5 months for a project that can be completed in one month, so the performance evaluation needs to be reduced.
A visitor said: you are sitting and talking without a backache. The evaluation of technical complexity and time is so easy. The human factors here can make the overall performance management completely different.
This official really makes you right:
It is difficult to estimate the technical complexity. A good architect may think of a complex project of B, which may be a in the eyes of a common engineer.
Time evaluation is not easy. Old employees can quickly understand their needs with familiarity with their business and systems, as well as their understanding of the company's internal resources. (They can learn from their own colleagues or find similar colleagues) it takes only two weeks for a new employee to complete the task.
This will make the actual performance management a mess.
We need to minimize the differences between the two in different team members, and this method is to use the statistical method + case method: to flip all the tasks that have been done out and re-evaluate the statistics. The members involved in the statistics should be as wide as possible, so that a relatively reasonable evaluation value can be obtained. For new tasks, similar to the UK case law, refer to the ratings given by previous projects. (Of course, whether the value is reasonable lies in the number of statistical tasks) There is also a trade-off about statistical coverage time, software technology is updated quickly, and new technical frameworks are usually used to improve the work (for example: in the age of webwork + spring + Hibernate and webwork + spring + hibernate, the time spent is different ). For complexity, using new technical frameworks + companies to continuously improve private platforms can reduce complexity to a certain extent. This is why I use technical complexity instead of "Business complexity.
Adding a weighted adjustment on this basis can theoretically make better performance management (the actual situation is hard to explain, and everyone knows what is going on ).
Because of the high cost, the actual work is not practical for small enterprises and project-oriented enterprises, or is not completed.

2. internal consumption of software companies
Because it is a team collaboration, the work of each developer needs the assistance of other colleagues. This is the internal consumption, including the transfer of knowledge, transfer of work, and assignment of work. For the company, we hope to improve competitiveness by controlling internal consumption. However, this kind of thing is often thankless!
Knowledge transfer. Document is the most traditional one, and document is also the most unreliable. Document Writing is laborious, and reading is also laborious. The writer often assumes that the reader has a certain understanding of the background requirements of the document and intentionally or unintentionally omitted some things (for example, the writer is familiar with the background requirements, I don't know how to write something.
Work transfer. The most common old code for new users has problems, so a group of people will re-write the code. It is also common that some tasks have nothing to talk about, but many details are very trivial (meaning there are many traps). The people who pass on do not know where to talk about them, and those who take over do not know the traps, it is often possible to keep asking questions later.
Work assignment. This is more time-consuming. Ask someone for help. The person is not busy. If the priority of busy tasks is not high, he does not know when to do well, especially cross-department tasks.
The XP development method seems quite effective in trying to solve this problem! Unfortunately, you have no chance to try it. If you pass by, please kindly advise if you have any experiences.

BTW, when evaluating the task's time, you must consider such internal consumption, otherwise ..... Hey!