Featured chapters of the mythical man-month

Chapter 2 Tar Pits
In history, nothing else is more shocking than the treasure of the giant beast in the tar pit. God witnessed the struggle of dinosaurs, elephants, and tigers in tar. The harder they struggle, the tighter the tar tangle, and no beast is strong or skillful enough to break away from the shackles. They sink to the bottom.

 

The development of large systems over the past few decades is like a tar pit where many large and strong animals are struggling. Most of them have developed a running system-however, only a few of them meet the requirements of goals, time schedules, and budgets. Various teams, large and small, complex and lean, one by one drowned in the tar pit. On the surface, it seems that no single problem will lead to difficulties, and every problem can be solved. But when they are entangled and accumulated together, the team's actions will become slower and slower. Everyone seems surprised at the level of trouble, and the essence of the problem is hard to see. However, if we want to solve the problem, we must first try to understand it.

 

Chapter 2 Mythical man-month
Brooks rule: Adding manpower to projects with low progress will only make the progress more backward.

 

Chapter 4 surgical team
In computer conferences, young software managers often hear that they like small and competent teams consisting of top-level talents, rather than those large teams with hundreds of people, the "man" here is of course a mediocre programmer. In fact, we often share the same view.

 

However, this naive view avoids a very difficult problem-how to create a large system within a meaningful time schedule? Now let's discuss every aspect of this issue carefully.

 

Chapter 2 aristocratic authority, democratic politics and System Design
The architectural consistency of the French city Reims is in stark contrast to the cathedral mentioned above. The design consistency is the same as those with unique characteristics. As described in the travel guide, style consistency and integrity come from eight generations of architects with self-discipline and sacrifice spirit, each of whom sacrifices some of their own ideas for pure design. Similarly, this shows not only the glory of God, but also the power of saving those who indulge in self-Pride.

 

Chapter 3 superfluous
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.

 

When designing the first project, he will face the ever-increasing decorative and skin-shining features. These functions are put aside as the content of the "Next" project. The first project will end sooner or later. At this time, the constructor is full of confidence in this type of system, master the relevant knowledge, and is always ready to develop the second system.

 

The second system is the most dangerous system designed by designers.

 

Chapter 4 Implementation
Assuming that a project manager already has a qualified constructor and many programming implementers, how can he ensure that everyone follows, understands, and makes decisions for the constructor? How can a group of 10 architects maintain conceptual integrity of a system developed by 1000 people? In the system/360 hardware design work, we found a set of methods to achieve the above objectives, they are also applicable to software projects.

 

Chapter 4 Why does the tower of Babylon fail?
So, since they have all these conditions, why does the project still fail? What else do they lack? Two aspects: communication and communication results-organization. They cannot talk to each other and thus cooperate. When cooperation fails, the work is paused. Through the lines of history books, we speculate that the lack of communication leads to debate, frustration, and group suspicion. Soon the tribe began to split-people chose to be isolated, rather than quarreling with each other.

 

Chapter 4
How long does System Programming take? How much work is required? How to make an estimate?

 

Chapter 1 scalability
This is also true for the creation of sophisticated, refined, full, and fast programs. The result of improving skills is often a strategic breakthrough, not just a technical improvement. Such a strategic breakthrough is sometimes a new algorithm, such as the fast Fourier transformation, or the complexity of the comparison algorithm is reduced from N2 to n log n.

 

More commonly, strategic breakthroughs often come from the re-Expression of data or tables-the core of the program.

 

Chapter 2 outline
I remember a project that changed every six months during the three-year development cycle. When a certain stage requires better performance, the instruction counter is implemented using a trigger. In the next stage, cost reduction is the main focus, and the instruction counter is implemented using memory. In another project, the best project manager I have ever seen often acts as a large Speed Wheel, reducing the volatility of market and management personnel.

 

Chapter 4 Preparations
Therefore, the management question is no longer "do you want to build an experimental system and then discard it ?" You must do this. The question is, "Do you plan to discard prototype development in advance or release the prototype to the user ?" From this perspective, the answer is clearer. Publishing a prototype to a user can get time, but it is costly-it is extremely painful for users to use; it disperses energy for developers to redevelop; it affects the reputation of products, even the best re-design is hard to recover.

Therefore, you must plan to discard it.

 

Chapter 2 do more
In terms of tools, even now, many software projects are still like a five-gold store. Every backbone engineer carefully keeps a set of tools collected during his career, which become an intuitive proof of personal skills. In this way, each programmer also retains tools such as editors, sorting, memory information dump, and disk utilities.

 

This method is stupid for software projects.

 

Chapter 1 Overall
Like in ancient mythology, there are always people in modern mythology who boast: "I can write systems that control air freight, intercept ballistic missiles, manage bank accounts, and control production lines ." The answer to these people is very simple: "I can do it either. Anyone can do it, but other people have succeeded ?"

 

Chapter 2 Disaster Recovery
When a front-line manager finds a planned deviation in his team, he will not immediately rush to the boss to report this frustrating news. The team can make up for the Progress deviation. He can come up with a solution or reschedule the progress to solve the problem. Why bother the boss? From this perspective, it seems pretty good. It is indeed the responsibility of frontline managers to solve such problems. The boss has a lot of real troubles to deal with, and he doesn't want to be disturbed by more problems. Therefore, all dirt is hidden under the carpet.

 

There are two ways to reveal dirt in front of the boss, both of which must be used. One is to reduce role conflicts and encourage sharing, and the other is to suddenly open the carpet.

 

Chapter 2 what's more
In the face of the "simple" procedures in those documents, most of us have been blackmailed to anonymous authors who are far away. As a result, some people try to instill in new people the importance of the document: the purpose is to extend the life cycle of the software, overcome the pressure of inertia and progress. However, many attempts failed, probably because we used the wrong method.

 

Chapter 1 no silver bullet
Among all the monsters of terror folklore, the most terrible is the wolf, because they can completely unexpectedly change from a familiar face to a terrible monster. We are looking for silver bullets that can eliminate wolves.

Software projects that you are familiar with have some characteristics (at least for non-technical managers) and often seem simple and clear, but it may become a monster that lags behind, exceeds the budget, and has many defects. As a result, we have heard of the call for silver bullet in desperate ways to find a sword that can reduce software costs as much as computer hardware costs. However, we can see that there has been no silver bullet trace in the past decade. Without any technical or administrative progress, it could independently promise an increase of magnitude in productivity, reliability, or simplicity. In this chapter, we try to find out the cause by analyzing the nature of the Software Problem and the features of many silver bullet candidates.

 

Chapter 4 on "no silver bullet"
It was claimed and concluded in "no silver bullet" that in the last decade, no separate software engineering progress could increase the software productivity by an order of magnitude (introduced in the 1986 version ). Now is the ninth year, so we should check whether these predictions have been fulfilled.

 

The Mythical man-month is widely cited and rarely has objections. In contrast, the article "no silver bullet" has aroused numerous debates, and the editors have received many articles and emails, so far, it has continued 3. Most of them attack their core points and my point of view-there is no mythical solution, and there will be no future. Most of them agreed with most of the ideas in the article "no silver bullet", but then determined that there was actually a silver bullet that killed the software monster-the silver bullet they invented. Today, when I re-read some early feedback, I can't help but find that in 1986 ~ During the 1987 s, the secret recipe that was once highly respected did not show the dramatic effect that was claimed.

 

Chapter 2 Views of man-month Myth: yes or no?
Now we know much more about software engineering than we did in 1975. In the Mythical man-month of the 1975 version, which views have been supported by data and experience? Which of the following points have proved incorrect? What other ideas are outdated as the world changes? To help with the judgment, I extracted the statements in the books of 1975 without any change and listed them in the form of summaries below-they were what I thought would be correct in the past: rules popularized in objective facts and experience. (You may ask, "if these are all the things in the book, why would it take 177 pages to discuss them ?") The comment in square brackets is the new content.

 

Chapter 2 Mythical man-month after 20 years
Why is the myth of man and month continued? Why does it seem to be related to current software practices? Why does it still have a group of readers outside the software engineering field, lawyers, doctors, social scientists, and psychologists who, like software personnel, constantly comment on this book and reference it, and keep in touch with me? How can a book about software development experience 30 years ago be related to the actual situation? Not to mention the help.