Last week, I visited the Shanxi Road Military Club and came across the 40th anniversary Chinese commemorative edition of "Myth of the Moon and Man". I turned a few pages and felt good, so I bought it and read it. I remember it was recommended by my teacher when I was in college. Ten years have passed and I have been working for eight years. If you have just graduated or done a small project with only a few people, you read this book and have done several projects with dozens to hundreds of people. Reading it again will definitely make a difference. At the beginning of the book, it is stated that we are talking about the development of large-scale systems. If a small team of several people sees the discussion in the book, it may be unbelievable. The main content is actually only more than 200 pages, but there are often flashing aphorisms to give you the pleasure of reading. Here are some excerpts:
On the surface it may appear that no single problem causes difficulty, and each problem can be solved, but as they become entangled and accumulated, the team moves more and more slowly. (Chapter 1 Tar Pits)
Dependency on other people is a real pain for system programmers. He relies on other people's programs, which are often poorly designed, poorly implemented, poorly released, or poorly documented. (Chapter 1 Tar Pits)
For creators, the incompleteness and inconsistency of our ideas can only be discovered in the process of realization. (Chapter 2 The Myth of Man-Month)
Using man-months as a measure of the size of a job is a dangerous and deceptive myth. It implies that number of people and time are interchangeable. The exchange of numbers and time is only applicable in the following cases: a task can be broken down among the participants, and they do not need to communicate with each other (Chapter 2 The Myth of Man-Month)
Adding people to projects that are behind schedule will only make them fall further behind. This is the man-month without mythology. The time of the project depends on the constraints on the sequence, and the maximum number of people depends on the number of independent subtasks. (Chapter 2 The Myth of Man-Month)
For computer systems, the vast majority of systems embody conceptual differences and inconsistencies far beyond Europe's cathedrals, although they typically did not take centuries to build. This is usually not because it was developed by designers of different eras, but because the design is divided into several tasks performed by several people. I argue that conceptual integrity should be the most important consideration in system design. (Chapter 4 Aristocratic despotism, democratic politics and system design)
Conceptual integrity requires that the design must be implemented by one person, or a very small number of people who have a tacit understanding of each other. And schedule pressure requires many people to develop the system. ( Chapter 4 Aristocratic despotism, democratic politics and system design )
The designers designed the 709's set of operations to be so rich and plentiful that only half of the operations are regularly used by customers. (Chapter 5 Superfluous)
The focus of any management task is when, where, who, what to do, and money. (Chapter 10 Outline)
New system concepts or new technologies will continue to emerge, and a system must be built to be thrown away, because even the best project managers can't omnisciently solve these problems in the first place. Ditching the prototyping concept itself is an acceptance of the fact - changing the design as you learn. (Chapter 11 Plan ahead)
In fact, major disasters are relatively easy to deal with. It is often related to major pressures, thorough restructuring, and the emergence of new technologies, and the entire project team can usually cope with them. The day-by-day lag at that time was difficult to identify, preventable by law, and irreparable. (Chapter 14 The disaster caused Xiao Qiang)
The law of memory loss causes the user-author to lose his understanding of the program, so he has to revisit the details of his labor. (Chapter 15 The Other Side)
Of course, I think the most quintessential part of the book is actually Chapter 16 The Myth of Man-Month, because it expresses my vague feelings over the years in refined and speculative language. Don't forget, this was 40 years ago. Here is a brief outline of the argument of the chapter:
1. All software activities can be divided into two tasks: primary tasks and secondary tasks. The primary task is to create complex conceptual structures that constitute abstract software entities. The secondary task is to express these abstract entities using programming languages. They map to machine language.
2. The so-called essential (essence) refers to the inherent difficulties in the characteristics of the software, the so-called secondary (accident) refers to the current production, but not inherent difficulties. So why is it a fundamental problem to construct extremely complex abstract conceptual structures? There are several inherent properties of modern software systems that cannot be avoided here: complexity, consistency, variability, and invisibility.
Complexity: Computers exist in many states, making it very difficult to conceive, describe, and test. The state of a software system is in turn orders of magnitude more than the state of a computer. Likewise, the extension of software entities is not merely the repeated addition of the same element, but must be the addition of different element entities. In most cases, these elements interact in a non-linearly increasing manner, so the overall software complexity is much more than non-linear growth.
Consistency: Physicists firmly believe that there must be some universal principle, either in quarks or in a unified field theory. A software engineer cannot take comfort in a similar belief that much of the complexity he has to master is arbitrary and unruly, derived from a number of human conventions and systems that must be followed. In many cases, because the latest software is being developed, it must conform to various interfaces. In other cases, the software development goal is compatibility. So a lot of the complexity comes from maintaining consistency with other excuses, and any redesign of the software can't simplify these complex features.
Mutability: Software entities are often subject to constant pressure to change. Part of the reason is that the software in the system contains a lot of functionality, and functionality is the part that feels the pressure to change the most. Another reason is that software can be easily modified - it is a product of pure mental activity and can be extended indefinitely. In short, software products are rooted in the matrix of culture, such as various applications, users, natural and social laws, computer hardware, etc. The latter is constantly changing, and these changes relentlessly force the software to change with it.
Invisibility: The objective existence of software does not have the physical characteristics of space. When we try to describe the software structure graphically, we find that it is a lot of interconnected and overlapping graphs. These graphs may represent control flow, data flow, dependencies, time series and namespace interrelationships, etc. One method of conceptual control built on the above structure is to force associations to be split until one or more graphs can be hierarchically layered. Despite structural limitations and simplification advances in software, software remains inherently unvisualizable, robbing some of the constructive creativity of powerful conceptual tools.
3. Based on the fundamental problem described in point 2, existing (here now refers to 40 years ago) high-level languages, object-oriented programming, artificial intelligence, "automatic" programming, graphical programming, better programming development environment And tools and so on are just some breakthroughs in solving minor difficulties. That is to say, these advances are all techniques to solve the huge difficulties in software construction. All technical work aimed at secondary difficulties in the software development process can basically be expressed as the following survival rate formula:
任务时间=∑（频率）*（时间）
而工作的创造性部分占据了大部分时间，那些仅仅是表达概念的活动并不能在很大程度上影响生存率。
4.因此，必须考虑那些解决软件上必要困难的活动——准确的表达复杂概念结构。这里作者给出了一些当时认为的有希望的办法：购买软件提供商的产品、需求精炼和快速原型、增量开发、卓越的设计人员。
以上是我所认为的全书之精华论述，四十年后再看还是熠熠生辉，其间计算机硬件性能的提升诚如摩尔定律所言，而软件开发的生存率却远达不到这般飞速，原因正是如上所说之大型软件工程中的根本问题。