What is the man-month myth?
People are programmers, month is time
1 person for 10 months, if it is equivalent to 10 people for 1 month
This is called a myth
Write at the beginning
I first heard the title of this book when I heard the teacher recommend it when I was just starting to learn the basics of Java in my freshman year. At that time, I also heard "Thinking in Java" and "Effective Java". Compared with these high-end domineering titles, "The Myth of the Moon" is more like a story-telling book, and it still has a fantasy color. I have read this book for some time recently, and it is indeed telling a story. It is a story of a failed experience. There is no fantasy. Through the failure experience, I reflect on various possible situations in the progress of the software project.
Someone once commented: This book does not teach you what to do, but teaches you what you should not do. It is basically a denial of a pseudo-common sense, rather than teaching you how to do things better.
From a confused face on programming and software development, to entering a development position after graduation.
From the perspective of a practitioner: It is not without reason that a book 40 years ago is still selling well. Although I don't understand what you are talking about, it seems to make sense to actually participate in the software development process. As an executive implementer, the experience is obviously different. Here, I will share my understanding of the deeper chapters.
Man-month myth
-
The lack of a reasonable time schedule is the main reason for the lag of the project, and it has a greater impact than the sum of all other factors.
What is a reasonable schedule? How to define the term "reasonable"? In the current market environment of rapid iterative development, time is the primary consideration, leaving aside the core issues of system complexity and technical difficulties. I think it is unreasonable to define the project from the perspective of time. I think a good product takes time to temper, and work slowly and carefully. From user interaction and user experience to follow-up maintenance and operation, expansion and upgrade, an excellent product must go through. If one-time development and one-time use, I think time is indeed the most important thing, I think this kind of situation is not within the scope of the book author's consideration.
The iteration of software products is more like a process from babbling to adulthood. The reasonable time schedule is 18 years. In this way, I think we all have the answer in our minds whether it is reasonable to promote growth.
-
Good cooking takes time, and certain tasks cannot be accelerated without compromising the results.
When it comes to cooking, the ingredients required for high-end dishes are extremely particular, including the amount of seasoning, heat control, and serving as a dish. Such dishes are works of art carefully crafted by the chefs. What about the creation of artworks and does not require ample time? I think it is similar to the first point here, both of which emphasize the influence of time on product quality.
Speaking of cooking, here is a soap flake of boiled cabbage, a famous national banquet dish: Is this the cabbage I know?
-
All programmers are optimists: "Everything will work well".
At this point, I think I have a say. As a developer, I must be confident. The code I wrote is free of bugs. If you don’t believe me, click it again. Huh, why are you doing this? Shouldn't it be that way?
Online rollover, 2333, everything will work well. From the perspective of normal operation, the problem is that you can't control the user's operation. Can you control your mind and let the user operate according to your ideas? Software development itself is the service industry, and our main clients are God. You can let God see that this product is working well.
Optimism is desirable, you must be optimistic, life is so difficult, no matter how optimistic it is.
In the development process, developers should consider the problem from the user's point of view, and consider all kinds of emergencies that may occur and solutions.
-
Since programmers develop through pure thinking activities, we expect that there will be no difficulties in the implementation process.
User-oriented development, products rely on business needs. Regarding business needs, I think the in-depth understanding of the business is incremental, and it is impossible to eat a big fat man in one bite. In the daily development and coding, you may encounter such and other business problems, and gradually carry out incremental business filling. Taking into account the closed loop of the overall business, based on the closed loop of the business, it is necessary to consider whether the business design of a certain place is reasonable. The consideration is still not only from the developer, but more from the user.
-
However, our own ideas are flawed, so there will always be bugs.
The perfect plan is modified repeatedly, not from the beginning. Since software development is a service industry, it cannot always meet the increasing or changing needs of users. It is precisely because of this that it is necessary to iteratively upgrade, gradually improve, and move forward toward the goal of designing a perfect software.
The defects mentioned here are not limited to design defects, coding defects, etc., but the ultimate manifestation of defects are all product bugs. Development is too difficult~~
-
The estimation techniques surrounding cost accounting confuse the workload and project progress.
人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。I think this bold and discolored text is the core idea of the chapter.
A woman can only give birth to a baby in ten months of pregnancy. Is it possible that ten women can give birth to a baby in one month of pregnancy?
It takes ten minutes for one cook to cook a plate of scrambled eggs with tomatoes. Can ten cooks do it in one minute?
Software development is incremental and requires pre-work to drive subsequent development, not based on independent work by personnel. Several people create a software product together, rather than each individual doing his own, and finally simply assembling it.
The man-month myth with a little irony is similar to the theory, and it really exists. In the face of cost and profit demand, there will always be such an irreconcilable contradiction. How to reconcile the contradiction between the two, if you ask me, I can't answer it, I think it is not only lack of experience, but also the software development that I understand exists in
乌托邦it. Just like when we were in school, books were an authoritative channel for our cognition and understanding. Today, the kaleidoscope of social reality is not what we imagined.Still too young~~~
-
Breaking down tasks among several people will cause additional communication workload-training and mutual communication.
This is also a pain point in the process of project advancement. According to my actual experience, the cost of communication is too great, and it is not even an exaggeration.
It's like a few people running a marathon together. Suddenly someone is involved, but the route is not clear and the progress is slow. You are halfway and he is at the starting point. At this time, someone needs to slow down or even retreat to connect with the members at the starting point, and then continue to lead the newly joined members to catch up. However, time has been passing by~, time will not wait for others.
When it comes to time, it really echoes the central idea of the full text.
-
Regarding the schedule, my experience is 1/3 planning, 1/6 coding, 1/4 component testing and 1/4 system testing.
Here I would like to talk about my views on the one-third plan:
需求阶段Part of the plan must include the requirements analysis stage. Requirements analysis has an important position in the entire software development process and serves as the basis for pre-work. Perfect demand analysis and reasonable demand landing requirements are necessary. As the saying goes, a good start is half the battle.
From the user's point of view, development is carried out through demand collection, demand analysis, demand screening, and demand landing. This requirement has emerged from nothing, and the process from general to clear is necessary and necessary. I admire those who can put ideas into words and convert them into actual needs for product design. These talents are pioneers and evangelists of software products.
-
As a discipline, we lack data estimates.
Data estimation is related to the control and management of the overall progress of the project, and the importance of experience here is obvious. Experienced is different from never experienced. Perhaps people have stepped on more pits than you have eaten. The ability assessment of experience cannot be quantified, but the manifestation of ability is reflected by the product.
A good PM will have an invisible force to control the overall situation.
-
We are uncertain about our estimation technology, so under the pressure of management and customers, we often lack the courage to persist.
Courage is not something you can have in the first "Courage." Utopian software development exists on paper rather than reality. So, in the face of reality, can "Courage" give you courage?
-
Brooks Law: Adding manpower to projects that are behind schedule will only make the schedule more behind.
-
The task reassignment itself and the work interruption caused by it;
-
Train new personnel;
-
Additional mutual communication.
-
Increase the overall workload necessary for the project from three aspects:
-
to sum up
In fact, all that has been said is just the tip of the iceberg in the book. Although the content on paper is very touching, it is still a difficult process to implement it into action.
Why is it difficult? 试错成本Too high. Looking back at history, change often means overthrowing and rebuilding. Who can guarantee that the experience of others is also applicable to oneself? The author tells us not to do this through practical examples, but how many people believe it? Even if they believe it, how many people really care about it and practice it?
The above content is purely personal, please don't spray if you don't like it. If there is any similarity, it is you who copied me~~.
Take the closing words in the book as the closing words of this sharing:
The tar pit of software engineering will continue to make people difficult and unable to extricate themselves for a long time in the future. Software system may be the most intricate thing in human creation, and people can only expect people to explore and try within their ability or just beyond their ability. This complex industry needs: continuous development; learning to use larger elements to develop; the best use of new tools; the best application of proven engineering management methods; good self-judgment and the ability to make us aware of ourselves Insufficiency-the humility given by God.