Software Engineering Management-Reading Notes on the Mythical man-month (Chapter2 ~ Chapter10)

Chapter 2 man-month myth

 
 

  
  Optimism all programmers are optimizers .... "This time she will certainly run" "I just found the last mistake". The second mistake in the month is the unit of work-man-month used in estimation and schedule. It implies that time and people can replace each other.
 
 
In terms of task breakdown, it seems that more people will reduce their work time. Otherwise, the increase in staff will lead to additional expenses such as training and communication, as a result, the time saved by task decomposition will soon be consumed, and sometimes the time may not be reduced. Do not aim to reduce the time for changes in personnel or project adjustments. Speed up is acceptable, but first, do not be greedy. Second, remember that speed is not satisfactory. The more people, the higher the efficiency.
 
 

  
  System development schedule 1/3 plan 1/6 code 1/4 component testing and early system testing 1/4 system testing. All components have been completed, not having enough time for system testing is a disaster.
 
 
Theoretically, the number of errors in the system development process must be zero. In fact, it is never possible for us to minimize the number of errors, it takes more time to test. Although the last bug may not be found, it is much better than the time spent... What do you do when the project lags behind? As a project manager, Alexander... If you increase manpower, the risks may increase like snowballs. Usually, project management increases too much uncertainty due to human factors, which is particularly difficult to estimate, maybe this is why the project manager is getting older and more popular. We can use experience to estimate the initial project budget and formulate the project plan. However, when there are new technical means, is it obvious that empirical estimation is used? Is there an excellent Estimation Model for planning ???
 
 

  
  To simplify the Brooks rule: increasing manpower to a team that is lagging behind will only lead to lagging behind.
 
 

Thinking, the management of open source software mentioned in the "The cathdral and the bazaar" article violates the Brooks Law, but it still succeeds. Why ????

Chapter 3 surgical team

 
 

  
  These studies show that the individual differences between high efficiency and low efficiency are very large and can often reach an order of magnitude. Mills recommends that each part of a large project be addressed by a team, but the team is constructed in a similar way as a surgical procedure, not a communication model with a team of 10 developers.
 
 
In fact, most of the current teams adopt this development method for development, but just as the question raised by the author, how to build a large-scale team is the most important thing, if a large team is established layer by layer based on the formation of small teams, conflicts will inevitably occur during the decision-making stage. How can this conflict be solved? How can we coordinate the progress and communication between small teams?

Chapter 4 aristocratic authority, democratic politics and System Design

 
 

  
  I hold that conceptual integrity should be the most important consideration in the concept of system design. The architecture must be separated by region. The architecture states what happened, And the implementation describes how to implement it. You must answer "yes" or "no" to the question of aristocratic authority ". There are only a few architects. The answer is yes... This is actually a kind of aristocratic authoritarian regime without any apologies.
 
 
The most dangerous situation is that programmers feel that there is nothing to do during the design process. In fact, they should be familiar with hardware and software platforms and grasp the preliminary knowledge in theory. At this time, the status should be that the designer has roughly designed the prototype of the system and determined the software technology and hardware platform involved in the system, therefore, programmers should be able to search for relevant information and supplement their knowledge based on this until the complete design is complete and coding starts.

Chapter 5

 
 

  
  When developing the first system, Architects tend to be refined and concise. He knows that he is not familiar with the ongoing tasks, so he will work carefully. A general tendency is to design the second system over too much and add many modifiers and ideas to the system. They were carefully placed in a secondary position in the first system.
 
 
The Chinese people say "the arts are brave" and "the swimmers are good". This means that you are always cautious at the beginning, which is usually human-like, this will be the first project in terms of both the project cycle and the specific implementation of the project are roughly in line with the expected development, will not bring about a large discrepancy, in the design of the second project, it often appears that "because of experience, I feel that I can add some secondary solutions to the design idea based on the background of my first success." It often fails, not just for projects, but for many things (do you have a psychological explanation ...). So what is the key to solving this problem? If it is designed with two architects (a newbie), the risk is reduced, however, once a newbie runs an independent project, it is inevitable that the second project will still encounter the same problem. Therefore, the project manager or the senior manager in charge of personnel assignment must pay special attention to this problem, or should this second design be placed in a project with lower risk? Reduce the loss caused by project failure. Or do system evaluators need to first evaluate the designed system scheme, and each improvement or functional design division must undergo a self-learned consequence assessment and risk assessment before implementation ?... This kind of book really depends on the actual case before analysis... (I am not a PM Material ;))

Chapter 6 Implementation

 
 

  
  The Manual describes the external specifications of the product. It describes and specifies every detail that the user sees. Similarly, it is the main design product of the architect. Accuracy is often more important than vividness. The regular weekly meeting is once a week, and every half day. Regular meetings are recommended to be held every 6 months. Solve the Problems Accumulated during weekly meetings. When the document conflicts with the machine, take the machine as the document is easier to modify.
 
 
This chapter focuses on the importance of documents and regular meetings. Documents are the only way to communicate with members of each project team. Regular meetings are a good solution to problems. When writing a document, you must note that at least two languages or forms should be used for description. One is the main description method, and the other is the auxiliary description method. This ensures that both developers and other project team members can have a more accurate understanding of the project. However, after implementation of the heaviest project, it is likely that it is inconsistent with the original idea. At this time, we should try to use the code on the machine and the program that can be run after testing as far as possible, instead of forcing modifications according to the provisions of the document, unless there are significant discrepancies (I feel this situation is unlikely to happen, and the weekly meeting is to avoid or avoid this risk ). Further minor revisions based on the document can serve as the iteration goal for the next stage to be theoretically nice (well... This is the natural optimism of programmers... (Optional values ;)). Why do the same person need to perform the commit writing in the document... Because the document must be consistent and consistent, it is more appropriate for one or two persons to organize the documents written by others, and during the process of writing the documents, it is better to explain some of the terms mentioned in the document for building and writing glossary separately (I feel that... It is still necessary to create a large project, and simply create a table or something. Otherwise, I will forget to write it at the end... Personal Opinion ). Normative Documents are actually quite important. First, there is no standardization in verbal communication. Second, there are too many colloquial things. Even if it is written, there will be such diversified expressions, not to mention verbal... So... Documents and regular meetings, which we usually despise, are essential. The reason why we do not feel the importance is that we have not participated in the development of large projects, or even medium-sized projects...

Chapter 7 why the tower of Babylon fails

The tower of Babylon has all the necessary conditions we think, and why does it fail.
 
 

  
  They still lack two aspects-communication and exchange results-organization.
 
 
In the original article, the obfuscation of God led to mutual suspicion between tribes, which eventually led to a complete project failure. In actual projects, it can be said that such obfuscation will inevitably exist, rather than being produced manually, first, a project may have different understandings between the user and the person who needs to obtain the requirement, after obtaining the personnel's understanding, it will have different meanings, not to mention escaping as a written language to formally become a document, even in the Process of reading the document, there will be confusing parts in the standardized documents, which reflects the importance of communication. Every person in the team must communicate actively in order to eliminate confusion during the communication process, ensure the normal operation of the project. All possible ways to communicate between teams are as follows:
 
 

  
  Informal channels: telephone... Meeting: regular project meeting Work Manual: formal project work manual should be prepared at the beginning of the project.
 
 
The work manual is not a strict project technical document.
 
 

  
  It is part of the organizational structure of a series of documents that must be produced by the project.
 
 
My understanding is that this so-called work manual is actually the project Wiki (note that the author of this book was written in 1986) and show diff options. • Organizational structure of large projects
 
 

  
  Let's take a look at the tree programming team and the basic elements required for each subtree to make them effective: 1. task (a mission) 2. Product owner (a producer) 3. Technical Director or Architect (a technical ctor or ect) 4. Progress (a Schedule) 5. Division of manpower (a division of labor) 6. interface definitions among parts)
 
 
In the arrangement of various functions, the role arrangement of product manager and Technical Director is the most difficult. Generally, there are several solutions:
 
 

  
  1. the technical director and product manager are the same person. Applicable to teams of about 6 people. Usually there are few people with both of these technologies. 2. The product owner directs and the technical supervisor acts as the right hand. This situation is quite difficult, and it is difficult for the technical director to establish its technical authority while not participating in any management work. 3. the technical director is the chief conductor and the product manager is the right hand. Or small teams.
 
 
When building a large development team, we often use product managers as decision makers. Can we think that in the future, there will be such a situation, that is, can the technical supervisor start to exercise in a small project, learn relevant management knowledge, and gradually transform the experience of serving as a deputy trainee in a large project to be competent as a product manager? That is to say, a good company should not only have good technical talents, but also a product manager should make a forward-looking decision on its products to reduce the corresponding losses. In summary, good internal and external communication and good team architecture are the key to the success of a project.

Chapter 8 is confident

 
 

  
  • Portman's data logs show that in fact his team only spent 50% of the working week on actual programming and debugging. The estimated mistakes can be fully explained by this situation. In short, estimation makes unrealistic assumptions about the number of technical work hours per year for each person.
 
 
According to the data description of Portman, we can see that it is impractical to make a complete estimate of the project as a whole only through the technical work of the project during the project, one of which is, in fact, estimation of technical work is very difficult. We usually have a certain deviation. In most cases, we estimate the time spent by the technology too much, in fact, more time is spent on non-technical aspects ;)
 
 

  
  Productivity is also divided into two categories: the productivity of the control program is about 600 instructions per person per year, and the language translation is about 2200 instructions per person per year.
 
 
This represents the status quo of development of large and complex systems.
 
 

  
  Productivity significantly varies depending on the complexity and difficulty of the task. The guiding principle for estimating the complexity of this "swamp" is that the compiler is three times more complex than the batch processing program, and the operating system is three times more complex than the compiler.
 
 
Summary:
 
 

  
  • Productivity seems fixed for common programming statements. This fixed productivity includes comments required in programming and may be incorrect. • With the appropriate advanced language, programming productivity can be increased by 5 times.
 
 
In fact, most of today's program builds are completed in advanced languages, and rarely use low-level command languages or machine languages. That can also be considered to be for different projects. Using different languages for development also has a certain impact on productivity. However, for the whole project, there may not be a huge increase in productivity. After all, the time spent on programming is not the most, and this part is not the most difficult. This chapter is difficult to understand. Although Brooks uses a large amount of data to explain it, it has neither participated nor managed large projects. Therefore, I still don't know how to compare images, so I will try again later. Now I only want to draw conclusions.

Chapter 9 scalability

 
 

  
  • The program space as a cost is the same as any overhead. the scale itself is not a bad thing, and an unnecessary scale is not desirable.
 
 
At that time, the hardware resources of the system were very valuable. Therefore, during system development, we had to calculate the hardware resources of the occupied system in detail to seek a larger benefit from the software and hardware, however, when the hardware seems so cheap today, we still need to pay attention to this problem. How to reasonably use limited hardware resources is the key, software that wastes users' hardware resources is not good software (<_<). In every software program development, hardware resources should be properly used, rather than being wasted without restraint.
 
 

  
  For project managers, scale control is both a part of technical work and a part of management work. First, it is clear that the overall size budget should be the same as the resident space budget, and the backend storage access budget should be the same as the scale budget. The second principle is also very clear: while specifying the size of the module, define the function of the module. The third lesson is that the project itself is very large and lacks management and communication, so that every team member thinks that they are the students who strive for small flowers rather than the personnel who build system software products.
 
 
That is to say, first of all, it is better to have a thorough and detailed understanding of the project size, and to be able to make a better division of each part, and then communicate and communicate with each other, regardless of the project size, communication is the most important. Every developer should consider it for the end user from the overall perspective of the project, rather than simply pursuing technical innovation and optimization of their own modules.
 
 

  
  • Space Skill 1: function swap dimensions. Skill 2: Consider the space-time compromise.
 
 
That is to say, the first method is actually to design the granularity of each part of the software during implementation. It is best to make the user customize it independently, in this way, the burden on developers is reduced, so that developers only need to pay attention to the small-granularity part. During the design, you need to design the interfaces of each part. The second idea is to design a public database, preferably two. One is to change space for time, and the other is to change time for space. In addition, I think the development of public libraries is more in line with the idea of software reuse. It is easier to maintain.
 
 

  
  Data Representation is the foundation of the program
 
 
In fact, most of the work done by the computer is data processing. Therefore, the data structure in the entire processing process has a great impact on the program performance.

Chapter 10 outline

 
 

  
  • Why should there be formal documentation first, it is necessary to record written decisions. Only after the records are recorded will the differences be clear and the contradictions be highlighted. Second, the document can serve as a channel for communication with others. Finally, the project manager's documents can be used as the data base and check list.
 
 
The content of this chapter is quite small and simple. It mainly describes the importance of the document, as shown in the Chapter title-outline. In fact, this is the main work of the document. At the beginning, we all wondered what the document was used for. Even for a long time, everyone was confused about the document, I think this document is a very irrelevant chicken rib. In fact, this is not the case. We think it is irrelevant. It is often done after the code is complete, on the surface, it seems that the ideal price comparison task can be handed over, because the project we are involved in is very small (can we use a micro-scale to explain it (<_< )). In large projects, it is actually a relatively formal project. The documents we want to write are actually very necessary and important, and the general skeleton of the software is defined, in fact, it is also a more favorable basis for exchanges between internal team members. The latest agility and limits are good. Some comrades simply think that there is no need to write documents, and the code is a document. I think it is inappropriate. unless there is a high degree of tacit understanding between the players, or the project needs and boundary specifications are very clear, there will be no ambiguity. Otherwise, the document is necessary, even if it is just a few words... Or, unless the code style is excellent, it can ensure that the quality of comments is quite high.