[Reprinted] is Microsoft's management model really worth boasting about?

Author:
Dick Sun's column

Original: http://blog.csdn.net/RichardSundusky/archive/2006/07/18/936001.aspx

Recently, a Mythical Man-Yue blog wrote a blog that boasted the art of Microsoft Management. This seemingly beautiful articleArticleIt is hailed as "best practice" by csdn ". I only have one comment on this blog-Na has ve !! I worked as a contractor at Microsoft for a year. Then I started an outsourcing project for Microsoft in a small company, and then I went to Microsoft for two months of consulting. I understand Microsoft's internal management. Is Microsoft's management model really worth boasting? My answer is "no ." The answer is obviously that Microsoft's management model is very problematic when Windows Vista is delayed several times.

"the three phases of Microsoft are more like a risk-driven, progressive" Spiral "life cycle model." Is this really what man-month myth says? None! Based on my experience in testing Windows Vista Mui APIs at Microsoft, Microsoft's periodic (or mileage) development cycle is more like the abnormal water design model ). The reason is that its attributes are nondescribable. It is neither cyclical (or mileage) development mode nor standard flow design mode. Imagine that a team has written the design concept of a vista component at the early stage of the cycle. By the end of the cycle, after the design turns into a Program , the test can catch up with the progress. Then the test finds that this design is often not feasible. What should I do? The entire design will be overturned in the next cycle, starting from scratch. This is why Vista has been postponed. Each part must be re-designed at least twice to three times. "A project usually uses 2/3 of the time for development and 1/3 of the time for stabilization" is impossible, because Microsoft's teams are very complicated and have too many performances, the test usually does not have time to test all corner conditions (Corner Case, boundary conditions) with all the performance values. Therefore, the test cannot find all the problems in a fixed cycle and stabilize the design cycle by 1/3 of the time. In fact, many companies have such problems.

When designing a part, Microsoft's design team usually spend too much time writing a plan, unlike the Mythical man-month's saying that "guiding a project with an imaginary description and a brief description of its characteristics", the design of a project must first write a refined plan, all the details will be listed in the plan before the program can be designed. I heard someone spent three months writing a plan. This is not a joke. After I joined the small company, a big guy told me. At that time, my chin fell for three minutes. Microsoft may have written a rough plan as short as possible. Try to explain that the product is not doing anything. However, it often appears that what the product does is not included in the plan. The results of the test show that some interface functions do not behave correctly, but do not know what the standard behavior of these interface functions is, in the past, the management thought that some behaviors were standard behaviors, while the developers thought that the behaviors they considered were standard behaviors. As a result, the developers wrote the functions themselves. Then the test reports program exceptions to the senior management, and the senior management notifies the developers to make changes. Instead, the developers return to the high-level decision. At the end of the meeting, we were able to determine the function behavior in two hours. The result is that these functions are used by other groups, and these actions must be modified to adapt to the applications of other groups. Then the error loop appears again. We can see the reason for the delay of Vista.

Microsoft's internal source code control is a rebuild of perforce. I heard that Microsoft bought a part of a company and modified perforce to turn it into a source code control software named sourcedepot. It uses the following command:

SD edit <File Name>

SD diff <File Name>

SD integrate <File Name>

SD Delete <File Name>

Sd help command ....

The so-called developers check the source code in every day, and then the tester tests the new build the next day. This seems very correct, but you have never imagined the difficulty? Let me give you some internal information:

Windows Vista requires 10 to 12 hours of construction time. The construction time of my group starts at every night and can only be completed at AM. Now everyone is in the company. You can start testing. How many Vista builds are there? Outsiders certainly don't know. When I leave:

Vista x86 pro CHK

Vista x86 pro fre

Vista x64 pro CHK

Vista x64 pro fre

Vista x86 ads CHK

Vista x86 ads fre

Vista x64 ads CHK

Vista x64 ads fre

Vista IA64 ads CHK

Vista IA64 ads fre

Here, there are 10 builds in total. It takes four or five hours to install these builds. Sometimes it takes one day for these builds to be installed. Then perform the test. It takes two hours to complete the two hundred tests. These tests can basically be completed in one day, and manual testing takes more time. It is only best to finish all tests in one day. If a build fails, only some tests can be performed in one day. If a problem occurs in other groups, such as a hardware driver, blue screen or even red screen will occur during each installation. The driver is uploaded to the source code branch at the higher level, then you can drop it down to the underlying source code branch. Hey hey, what you encounter is the failure to install and test for a week or even a month. I encountered this problem three times in the last year. We can see why Vista was postponed. (For a bit of internal information, the source code branch of Windows Vista should be divided into at least three layers: winmain, vbl_core, vbl_core _ <group branch>. At the end of each group's cycle, upload your source code from your own branch, and other groups upload the source code changes to your branch every day ).

"Microsoft developers usually use VB to construct a user interface prototype. However, painting brushes are also a useful tool for building computer screen models. The rigid description turns into a biological document, which should not be too detailed or limit the invention and creation ." This is purely fart. The source code of all products is written by C and Win32 APIs, or by ATL and C ++. It seems that it is not used for internal connection to MFC. All testsCodeIt is written in C ++ or C. Why? It is necessary to ensure the program running speed. The graphic presentation on the user interface is made up by a third-party company using professional software such as Photoshop and then handed over to developers for design. These third-party companies are generally specialized in user interaction research. At least all the Windows Vista source code I see is written in C.

Microsoft does not emphasize iterative development and gradual refinement. Many groups emphasize that the drop iterative development model cannot be used. Some groups do use iterative development, but their practice is still the flow mode, not very professional iterative development. This outsider cannot know at all. Therefore, do not draw conclusions easily.

In my group, the document requirements are extremely high. The behavior of a function is usually determined by four or five meetings for two or three hours. There are often a variety of different behaviors that lead programmers and PM argue about. Finally, the leading programmer can win in the debate, or the deadlock arises, and the next meeting will continue to debate. Such Hesitation often leads to project delays, and some performance is pushed to the next development cycle, resulting in project delays. It is common for a behavior that determines a performance to be dragged on for two weeks. Testing is often at a loss of control and does not know how to perform a test, so the tester starts another test, in a few days, I will ask the developer whether the performance is determined.

The biggest headache for testers is Microsoft's experts who often hire developers at Microsoft, who are able to design hard-to-understand but well-functioning program segments. I admit that I cannot compare with these people, so I didn't get a full-time job. However, I found that these people like to complicate the simple design. Microsoft's slogan may be that a non-complex program is not a good program. This is why Windows Vista requires a GHz CPU, 1 GB memory, and at least MB graphics card. If you don't upgrade, you don't want to run Windows Vista. Guess how it works? When Vista came out, I had to install Linux and turn myself into a Linux User. I have already brought my wife a MacBook. I have nothing to do with windows.

Now, I have tested functions or Windows Live! The login session is extremely complex. A simple Windows Live! There were 50 or 60 types of login sessions, and then combined with other functions such as Ajax, there were 200 or 300 types of behavior. I wrote more than one hundred tests in two months, and I didn't give a one-to-one test of the boundary that can be covered. The worst thing is that no one can tell me what behavior is correct. When I write a test unit, it is like a fish in the water. Later, my wife went to San Diego to study for a doctorate. I found a formal job in intuit and escaped from Microsoft's test hell. In the last two months, I felt very miserable. This is also true for several Mui APIs I have tested. There is no comprehensive document to describe the specific behavior of a function. You can only participate in various meetings and obtain relevant information to develop test units, refresh the test unit without stopping.

The most ridiculous thing about me is that every manager has his/her own plan. When a meeting was held, he thought that a certain topic was the center of the meeting. As a result, one of the managers would occupy the meeting, and demonstrate self-righteous topics, so that everyone does not know the specific direction of the meeting. I remember the most profound one is that the head of our testing organization is Jae Choi. I attended a meeting to discuss the performance of Mui API. After three days of testing, I brought a bunch of data into the meeting. I didn't see it. Then Jae Choi took control of the meeting, in a big speech, we need to design a complex and perfect performance testing framework, automate all tests, and then examine performance data in each design cycle. As soon as I heard it, it would take at least three years for such a framework to be established. At that time, Vista was available in the morning and it was not feasible. I don't know how much he knows about my work, and then he just points out his fingers. One of my colleagues shook his head helplessly after hearing this, and later my immediate leadership advised him to put his unrealistic plan aside. The former employees I contacted later told me that some of Microsoft's internal experts are stupid, and some are leaders. This uneven combination often leads a design to the tip of the horn. The time has been wasted when the system is about to return and start again.

It is not always a problem at Microsoft. Microsoft is like Nanmu Bay. Everything is self-reliant. Each group has its own testing framework, and Microsoft has its own automated testing tools, windows Test Technology (WTT ).Source codeEveryone can help their colleagues, provide test tools, or suggestions. You will be able to learn a lot after a year of experience. What you learn is technology and the way you do things you need to survive. With these two technologies, you can basically succeed in any field of the U.S. software industry. But is Microsoft's management model worth advocating? Not worth it.