The book of People's Month myth

The story of the People's Month

Frederick P.brooks,brooks is considered "the father of the IBM 360 system" as a project manager for 360 Systems and a manager for the 360 operating system project design phase. With outstanding contributions to the above projects, he, Bob Evans and Erich Bloch won the National Technology Award in 1985 (Nationally Medal of Techology). Earlier, Brooks worked as an architect for IBM stretch and harvest computers.

See so rich life resume, can not help but envy and praise, "People's Month legend" is his pen a classic.

The article begins with tar pits (the tar pit), tar pits, let the beast trapped in the lunar stone struggle, the more difficult to break free from bondage, eventually into the pit bottom. and large-scale system development is such a tar pit, a variety of problems tangled together, let a person deeper and deeper, there is no way to see the nature of things. In which, do not be a pure optimist.

"People's Month myth", what is the person month? is the unit of work that is used in estimates and schedules. Brooks believes that employing the month as a measure of the scale of a job is a dangerous and deceptive myth. It implies that the number of people and the time can be replaced by each other. The exchange of numbers and time only applies to situations where a task can be broken down to the participants, and they do not need to communicate with each other.

Keep the concept of the design intact. Whether for small software or large software, must be a designer-led, up to two people to discuss together to complete the overall design of the software. As a software, a system, must have a clear and clear conceptual model, everyone in this framework work, all the innovation development must be consistent with the basic concept. The concrete implementation personnel can refine the concept, but only the general designer has the power to negate and develop the basic concept. One thing to note is that even the general designer has always been the same person, and the rules or concepts that he takes for granted in his mind are probably not a common concept for all developers because they are not clearly documented. When other developers code, it is possible to generate something that contradicts the concept (modules, functions, algorithms), resulting in a deterioration of the overall structure. This time, the general designer must immediately find out, make corrections. This is the surgical-style development team.

Here is a brief summary of each part of the human moon myth, and it is in place.

Tar Pits

1. The workload of the programming system product development is nine times times that of individual-use, independently-developed component programs.

2. Some inherent distress in the programming industry:

The most difficult part of learning programming is to adjust the way you do things to the pursuit of perfection.

Others set goals and must rely on things that they cannot control.

The real authority comes from the completion of each task.

Any creative activity is accompanied by tedious and laborious work, and programming is no exception.

People often expect projects to converge faster (bugs, hours of work) at close to the end, while software projects are getting closer to completion and slower to converge.

The product is nearing completion with the threat of obsolescence.

Human Moon Myth

1. The lack of a reasonable time schedule is the most important cause of project lag, and it has a greater impact than all the other factors combined.

2. Good cooking takes time, and some tasks cannot speed up without compromising results.

3. Our ideas are flawed, so there will always be bugs.

4. We have confused the workload and the progress of the project around the estimation techniques for cost accounting. Man-month is a dangerous and deceptive myth, because it implies that the number of people and time can be replaced by one another.

5. The decomposition of tasks among a number of people can lead to additional communication workloads-training and communication.

6. With regard to scheduling, the author's experience is 1/3 plan, 1/6 code, 1/4 component test, and 1/4 system test.

7. Because we are uncertain about our own estimation techniques, we often lack the courage to persevere under the pressure of our management and our customers.

8. Brook rule: Adding more manpower to a project that is lagging behind will only make progress more backward.

9. The deployment of additional staff to software projects has increased the overall workload of the project from three areas: the reallocation of tasks itself and the resulting disruption of work, the training of new personnel, and the additional communication with each other.

Surgery Team

1. There are also two years of experience, and with the same training, good professional programmers are 10 times times more productive than less programmers. On this one, I saw in extreme programming that Sackman and Humphrey did experiments to find that good programmers work more efficiently than poor programmers by up to 28 times times.

2. Small, lean team is the best. This is fully reflected in software process and extreme programming.

3. A team of two people, one of whom is a project manager, is often the best way to use people.

4. For a truly large system, a small, lean team is too slow.

5. In fact, the experience of the vast majority of large programming systems shows that swarmed's development approach is costly, slow and inadequate, and that the products developed cannot be conceptually integrated.

6. A lead programmer, a team structure similar to a surgical team, provides a way to achieve product integrity that is produced by a small number of minds, as well as the overall productivity of multiple facilitators, and to drastically reduce the amount of communication involved.

Aristocratic autocracy, democratic politics and systematic design

1. Conceptual integrity is the most important consideration in system design.

2. In order to achieve conceptual integrity, the design must be done by a single person or a small team with a consensus.

3. For very large projects, the separation of design methodologies, architectural aspects and specific implementations is a powerful way to achieve conceptual integrity.

4. Discipline and rules are good for the industry. External architectural provisions are actually augmented rather than restricting the implementation of the group's creativity.

5. Many of the work of architecture, design implementation, and physical implementation can be carried out concurrently.

Gild

1. Early communication and continuous communication will enable the architect to have a better sense of cost and to give developers confidence in the design and will not confuse their respective division of responsibilities.

2. How the architect succeeded in influencing the implementation:

I. Bear in mind that the developer is responsible for the creative realization, and the architect can only make recommendations.

II. Listen to suggestions from developers on architectural improvements.

3. The second system is the most dangerous system that people design, and the tendency is to design excessively. This may be true, but this is a problem that cannot be avoided, and it is impossible to have someone who has developed a third system experience without developing a second system experience.

Implement

1. Even for large design teams, the design results must be completed by one or two individuals to ensure that these decisions are consistent.

2. There must be a clear definition of where the architecture differs from the previous definition, and the level of redefinition should be consistent with the original description.

3. For the sake of accuracy, we need a formalized design definition, and we also need a narrative definition to deepen our understanding.

4. It is important to allow an architect to make a phone answer to an implementation person's query, and must be logged and collated.

5. The best friend of the project manager is the enemy he faces every day--an independent product testing agency/group.

Why would Babel fail?

1. The failure of the Babel project is due to the lack of communication and the organization of the results of the communication.

2. Because the left hand does not know what the right hand is doing, so the progress of disaster, the unreasonable function and system defects appear. Because of assumptions about other people, the understanding between team members begins to deviate.

3. The team should communicate with each other in as many ways as possible: informal, regular project meetings, brief technical presentations, shared formal project work manuals.

Answers

1. An accurate estimate of the entire work cannot be obtained by simply estimating the coding section and multiplying the relative coefficients of the other parts of the task.

2. Data for building standalone small programs is not available for programming system projects.

3. Program development and program size exponential growth trend.

4. When using the appropriate high-level language, the productivity of the programming can be increased by 5 times times.

Fits

This chapter is mainly to solve the contradiction between the project investment and disk space and memory, but this contradiction in the development of computer hardware to the current level can be ignored.

Sketchy

1. Requirements for software projects: objectives, user manuals, internal documentation, progress, budgeting, organization chart, and workspace allocation.

2. Even for small projects, project managers should standardize the above-mentioned series of documents early in the project. This chapter emphasizes the importance of the document, but does not take some dogmatism to convince you of the importance of the document, but gives the project manager practical steps.

Rainy day

1. For most projects, the first developed system is not a suitable one. It may be too slow, too large, difficult to use, or all three of them. System discard and redesign can be completed in one step, or can be implemented in chunks. This is a step that must be completed, and if the first system discard prototype developed is released to the user, it can get time, but it is expensive. For the user, the use of extreme pain, for the re-development of the people, distracted, for the product, the impact of reputation, even the best redesign is difficult to restore reputation.

2. The user's actual needs and user perception will change as the program is built, tested and used.

3. The easy-to-grasp nature and invisibility of software products has led to a permanent change in the needs of its builders.

4. Some normal changes in the goals and development strategies are unavoidable, and it is much better to prepare them beforehand than to assume that they will not appear.

5. For a widely used program, the total cost of maintenance is usually 40% or more of the development cost.

6. Maintenance costs are severely affected by the number of users. The more users, the more errors they find.

7. Campbell points to an interesting curve that shows the number of monthly bugs in a product's lifetime, first falling and then climbing.

8. Bug fixes will introduce new bugs with a probability of (20-50)%.

9. After each repair, all previous test cases must be rerun to ensure that the system is not compromised in a more subtle manner.

10. Similarly, fewer people are designed to implement, fewer interfaces, and fewer errors are generated.

11. All modifications tend to undermine the architecture of the system, increasing the degree of confusion in the system. Even the most skilled software maintenance work only slows down the process of system degradation to irreparable confusion.

Gan Moye

The project manager should develop a set of strategies and allocate resources for the development of common tools, while at the same time he must be aware of the needs of professional tools.

Huoqixiaoqiang

1. The day-to-day progress is more difficult to identify than a major disaster, less easy to prevent and more difficult to compensate.

2. The first step in controlling a project under a rigorous schedule is to develop a schedule that consists of milestones and dates.

3. Milestones must be specific, specific, measurable events that can be clearly defined.

4. If the milestones are defined so clearly that they are not self-deceiving, programmers rarely cheat on the progress of milestones.

The Other Side

1. For software programming products, the appearance of the program to the user is as important as the content provided to machine recognition.

2. Even for programs that are fully developed for their own use, descriptive text is necessary because they are forgotten by the user and the author.

3. Documents can stimulate the programmer's ability to overcome laziness and progress during the entire software development life cycle, but it is difficult to successfully instill a positive attitude toward the document to programmers.

4. In order for documents to be maintainable, merging them into the source program is essential, rather than being saved as a standalone document.

No silver bullets.

The legend of the wolf may have been heard or may not have heard, the human wolf is a kind of human and wolf characteristics of the terrorist species, and silver bomb is to eliminate it is one of the most effective bullets, if you read the "Vampire legend" may be able and easy to understand this point. The author compares the software development to the human wolf, and compares the method of improving the software development efficiency to the silver bomb. The author predicts that in the next decade, it is impossible to try to improve the efficiency of software development by looking for an effective silver bullet that can increase the effectiveness of one or even several orders of magnitude.

No silver bullets. The author lists some of the most advanced technical or ideological concepts at the time, such as ADA and other advanced programming languages, object-oriented programming, artificial intelligence, expert systems, "automatic" programming, graphical programming, program validation, environment and tools, workstations, etc. Although these advanced technologies have improved the efficiency of software development to a certain extent, the effect of silver bullets has not been achieved. From the author's prophecy has been more than 20 years, throughout the current software development, although new technology in the endless, but there is no silver bullet can let software development to produce a revolution.

Tar pits still exist

The tar pits of software engineering will continue to haunt people for a long time to come. Due to the variability and complexity of the software system, this industry can only be a step up the ladder, and the hope of silver bombs in the time frame we can imagine is very slim. We will fight the tar for a long time.

Why this book will become a classic, and the author of the indelible idea of inseparable relationship.

The book of People's Month myth