A bean-style book review in The Mythical man-month

The Mythical Man-Month is a milestone in The software industry. The author, Brooks. In the book, he discusses in detail all aspects of the entire process of software projects, including schedule planning, team composition, documentation, and troubleshooting. This article examines the reason for the success of the book, further analyzes several key issues involved in the book, and looks forward to the inspiration that the book may bring to the Chinese software industry.

Starting from dimensions

Mr Bean, Mr Bean, approves of the portrait of the painter's mother. The first thing to talk about is: "This painting is quite big (quite big), so excellent )". This criticism routine has existed in ancient China: When tea is made, praise "hot" is. Today, let's talk about Brooks' "The Mythical Man-Month" (translated as "The Mythical Man-Month", hereinafter referred to as MMM), as well as experts from The UK, starting with dimensions: one of the highlights of this book is that it is relatively small.

There are two points. One is to open the book and the other is the number of pages. Nietzsche said that my ambition is to say in one sentence that ten other books can tell clearly (he added a sentence-or even a thing that ten books cannot tell clearly ). However, for the publishing industry, such a publisher should not. The majority of books are long because they have a lot of clues about the fields involved, but they can always use the Chinese saying: he has no time to write in the short. Short writing is not something everyone can do. IT requires a good sense of separation and Structure-IT is difficult to find a quality among IT practitioners in a hurry. It is based on general technical books, mostly for people, high horse and high horse (of course, there is also the usual practice of domestic photocopies, the original large open book is printed into a small brother, but considering the increased reading difficulty, the results are not as economical as you think ). "Big", for books, especially technical books, is not necessarily "amazing ". In my personal reading habits, more than five hundred pages, more than 32 large technical topics, it can only be used as a dictionary query, like the old palace lady in the palace, even a flirt can also be done. If you want to get a three thousand pet set, you will not be able to share it with others. This is a roll in the hand, as soft Yu shengxiang In the hug, always to "light", "thin" for the wonderful, if Pang ran giant thing, the body of the wolf, it is inevitable that people will have psychological barriers (in this corner, I would like to greet everyone who has read "C ++ Primer": You can all go to the Emperor of Yanfu Qi Tian in "The Big inner secrets ). The MMM mentioned now is just Zhao feiyan in the technical book, which can be literally used as a palm Dance: The big 32 book, the comments and indexes on a total of 332 pages. What matters is that, A large amount of space before each chapter is left to the question map and question mark. After Chapter 19, the content to be read is less than 200 pages.

If you decide to read this book, you may be able to make a budget based on my personal experience: not a fixed book plan, but to kill the boring time on the morning bus, I chose this human-looking and illustrated MMM (its predecessor appeared to be the pocket-sized Captain Scott ). On Sunday afternoon of The previous week, I happily covered The three chapters at The end of The book: "The MMM after 20 years ") the author's famous single paper "No Silver Bullet" and "No Silver Bullet Refired, several chapters under Chapter 1 are evenly distributed at the speed of Chapter 1 and Chapter 2 each time during the early peak hours of five bumps (about 35 to 40 minutes each time, last, a sleepy Saturday morning made me finish the rest-I can't believe it, this kind of "casual" reading method applies to any other technology "(the possible exception is eagleware, which we will talk about later) -- maybe you will bring it to Planning XP tomorrow morning.

Delicious Analysis

So what are the advantages of this book besides being small? Right, and then: it is better to read. I read books simply by appearance, and my appearance is everything (skin is the most profound part of a person, French say ). Just like the food, "delicious", nutrition, etc. In the eyes of our elders, it is still the second meaning, but it comes out of the intention of "spiritual food, "Good reading" should also be the highest praise for the book.

Good reading has two meanings: easy to read and delicious to read. Not all books are easy to read (I have heard of logical philosophical theories?), Easy-to-Read books are not all delicious (some easy-to-read books are easy-to-read, but just like xiao'er Zhike syrup, it's an insult to your intelligence-are you still using Yu Qiuyu ?) However, for a technical book, it is also a great achievement to clarify its subject and make it easy to read. Some people write books and work hard on "inner beauty". But they do not know that "closeness" is the first link: do we not say "delicious" or "cute? "Yes" (also the ability in accessibility) is the most important.

Return to the topic and talk about the conclusion of the book: I have this commemorative MMM Edition (Anniversary Edition ), A total of 19 chapters (there is also a brief preface-the first version and the next version each-and the end ). Among them, chapters 1st to 15 are the first version of the content, the longest one is 17 pages, the shortest fifth chapter is to partition the question map and the question, but the thin two half paper. The author calls these chapters "essays )", each chapter handles relatively independent topics ("man-month" issues, software project personnel composition, communication in development, documents, troubleshooting, etc ), therefore, you can start from any section you are interested in, regardless of the relationship between chapters. In Chapter 4 at the end of the book, Chapter 18th "Proposition of MMM: True or False? "Is a list of all the views of previous chapters-a very convenient review and review setting; the other three chapters (for the two discussions and Post notes of" Silver Bullet) the length is 20 to 40 pages, which deserves special consideration. The author did not revise the original content one by one for a technical book of the first version that was just a few years ago. Instead, he chose to reprint these chapters, at the same time, I will review the gains and losses based on the technical and cognitive changes over the past two decades.

Now, you can see the book in a fuzzy way: It's very thin, it's very short to flip each chapter, and it contains a lot of illustrations on the whole page (from the side, the color of the pages is black and white ). In other words, readability first comes from the appearance. When you pick it up, you will immediately feel delicious.

Then you will notice the style of the book. In terms of the Language Style of the original technical book, I once made a distinction elsewhere: readable/translable (a poor imitation of another well-known French concept ). The "readable" style is mainly used by writers who write in their mother tongue. They are able to use the elements of language freely, and almost always find the most appropriate expression of a specific concept. These expressions are often rooted in the language itself, so it is difficult to convert them into another language. For example, the title of the chapter titled "system space limitations" is "ten pounds in five-pound sack ". For anyone who has the English proficiency in the college entrance examination, the meaning here is very intuitive, but who can give their Chinese equivalents easily? "Scalability "? (I happen to know what the Chinese translation is .) "Ten lbs in five lbs of hemp bags "? On the other hand, the "printable" text is mostly a product of immigrant writers. For a concept, they lack a "natural" expression. They place strings of words in other languages like furniture borrowed temporarily. You can simply translate such text word by word, or even use machine translation without making a major mistake (from the OOSE of Jacob's et al: "When strong semantics are provided at the behavioral description level for all of these fundamental issues, they radically affect the selection of an appropriate resource structure. "), but it is difficult to understand what he is talking about right away, no matter whether it is translated or not. Of course, this can only be the most simplified 0-level simulation of the actual situation (some local writers who like to add slang in the line almost cannot be classified as any side ). But when I say "readable", the first thing I think of is Brooks and another master Martin Fowler. There are many similarities between the two styles: being friendly, not showing off, and being able to explain in the most common English (sometimes desperate for Chinese.

The author of this book, Brooks (maybe it should be said "small", because his full name is "Fredrick P. brooks, Jr. ") He was a development project manager and later transferred to the university for many years, therefore, it is difficult to have a world-class level in actual project management and teaching. After leaving IBM for nearly a decade (1975), he wrote a book based on a large amount of practical and teaching experience. In terms of style, he also had the patience of teachers and the technical qualities of engineers. I personally benefited most from the wonderful metaphor that is everywhere in the book. Just a few examples: "Tar pitfall", "Cathedral", "surgical team", and "Silver Bullet". In my memory, almost every one is the most appropriate description of the object. However, the brilliance of these metaphor is also achieved through reflection of numerous questions and inscriptions (sometimes humorous.

In many cases, excessive pursuit of "sense of humor" can also produce cough syrup effect. A typical example is Peopleware. Compared with MMM, the book always impressed me with the salesman's teaching materials. The author's technical background (I don't think DeMarco was involved in serious software projects) and different religious backgrounds (Brooks is a devout Christian) it may be helpful to explain the gap between manipulation and simplicity, empty and heavy.

Inspiration from French restaurants, surgical platforms, and werewolf

Let's review Doudou's criticism practices. In my opinion, it has the characteristics of formalism that are hard to recognize: It mainly considers "external" elements, formal elements (such as the size of the painting, ignore the actual reproduction content of the work-we remember the wording of the old lady mentioned in the painting by Bean: the ugly old bat on the cactus ("a hideous old bat who looks like she's got a cactus lodged up her backside "). Should I also adopt such a policy? Readers (I imagine that most of the readers who see this book review are technical experts) may laugh at it for a bid. In addition, the content of MMM is far more talkative than that of "old bat. But even so, it is unrealistic to examine the points in the book one by one: first, no one is better than the author has done. If you really need them, you should go to chapter 1 of the original book. Second, the book does not have a consistent central idea that can be extracted. For example, communication, documents, troubleshooting, tools, and other fields, each of them deserves a special article for careful discussion. After consideration, I decided to talk about the content that can be recalled without rereading the original book-that is, my bus reading practice (basically a Qualcomm filtering process) the essence of survival.

Man-month

The first is "man-month )". Everyone familiar with software project management must be clear that people often estimate the workload based on man-month (and charge accordingly). For example, if a five-person project is completed in two months, the total workload is 10 man-month. This book uses this name to apply the terms of the recording industry. It can be said that "man-month myth" is the main article of this "album", except for the second chapter titled it, there is not much content related to this.

The author's intention is not to completely deny the man-month as the metering method, but to clarify the illusion hidden in this concept. Based on my diligent and unreliable memories, the main conclusions here include: 1. it cannot be converted between persons/months. In other words, if two persons are finished in five months, they cannot be completed in two months. 2. (also the most controversial point) increasing manpower after the project can only delay the construction period. the larger the project, the more people a month is needed for work. In other words, the author wants to smash the myth that the concept of "man-month" can be linearly grasped: whether it is the number of developers or changes in the workload itself, may cause nonlinear changes in the final completion time. The author's dramatic expression is: Adding manpower to a late software project makes it even later. in fact, this point of view is not as challenging as it looks. In the first and later versions, the author said that it contains reasonable exaggeration. In the latter's note, he even quoted further research as saying, increasing Manpower does not necessarily delay the construction period, but it will definitely reduce the engineering efficiency. The sooner you increase the manpower, the better.

The main consideration of this conclusion is to increase the hidden costs (staff training, communication costs when multiple people work) and the insurmountable Key path (crucial path) in the project process ). For project managers, this is a self-evident truth. However, due to the pressure of the final decision maker, the actual project often violates this circumstance. The author inserted a French restaurant menu into the book as a question map. I also suggest you learn the sentence on the menu: Faire de la bonne cuisine demande un certain temps. si on vous fait attensid, c'est pour mieux vous servir, et vous plaire (it takes some time to cook well. If you are asked to wait for a while, it is to make you happy .) This is a good barrier for French-speaking customers/bosses.

Conceptual integrity

If you must find the concept that runs throughout the book, "conceptual integrity" may be regarded as one. The addition of some features (anomalous features) should also ensure that the entire system embodies a complete set of design concepts: this is the meaning of introducing conceptual integrity. Beneficiaries of conceptual integrity include end users, system developers, trainers and service personnel. Systems with well-maintained conceptual integrity are easier to use, requiring shorter training and learning time, and at the same time easier to develop. However, in the practice of software production, decision makers at all levels can easily emphasize "functions" and ignore the tendency of conceptual integrity. Therefore, we can see that there are too many "functions", and the overall system of the Alibaba Cloud, there have also been many cases where the development of the entire system is delayed or even hard to work due to the difficulty of implementing one or two additional functions.

Therefore, the author puts forward that conceptual integrity is the most important consideration in system design. In terms of conceptual integrity, I think the two points proposed by the author are the most interesting. First, we need to overcome the "second version effect (the second system effect)" of the system )". When designing the first version of the system, a system designer often has a weak self-confidence and best effort, and will try to tailor the number of functions to be implemented. When the first version of the system is successfully released and the design of the second version starts, a large number of previously suppressed proposals will be reproduced as confidence increases, designers are no longer so conservative when inserting new features. This is likely to result in a bloated, conceptual integrity-less second version of the system (the author's 1995 example is Windows NT after Windows 31 ). Second, the effective organization of the entire project team helps to ensure conceptual integrity. First, we need to distinguish between product personnel and developers, such as effecect and implementer. The impact ect mentioned here is equivalent to the product manager in general. Only him and a few people can determine the overall product requirements, rather than leaving the most subtle requirements to developers. In the process of determining requirements, repeated requests, including feedback from developers, are necessary. However, to ensure conceptual integrity, a few or even one person must make a decision. In addition, during development, you can consider the "surgical" Development Team, that is, the only "surgeon" (technically danale) A team composed of multiple assistants, testers, contacts, documents/tools/configuration administrators and secretaries. Clearly, the core principles of both product/developer differentiation and the introduction of surgical teams are: 1) Functional subdivision; 2) focusing on a few people with high requirements. In fact, the author said in other chapters that one of the best ways to improve the quality of software projects is to find a person. The difference between a "great" designer and an ordinary designer is greater than that before and after any advanced tool, methodology, or management model.

Silver bullet and others

In addition, the "Silver Bullet" in the supplementary part is another original concept of the author. In ancient werewolf legends, only silver bullets can be used to conquer impermanence monsters. Therefore, the author uses the word "Silver Bullet" to name the hard-winded monster of the uniform software project that people desire to find. "No silver bullet" means that there is no way (either technically or managerial) to leverage the existing software development productivity (reliability/conciseness) increase by an order of magnitude.

The author's argument is concise (in my opinion) effective: the difficulty of software development comes from two aspects: essentially and incidental (similar to the opposition between the essence/even nature in the philosophy of the Institution of Economics ). Essential difficulties are inherent in software development and cannot be canceled in any way. Accidental difficulties are non-essential factors, it can be eliminated by introducing new tools, methodologies, or management modes. The key is that, as long as the essential difficulties consume more than 10 percent of the workload in software development, productivity cannot be increased by 10 times even if all the occasional difficulties are eliminated.

Just like many other arguments of the author, after reading the silver bullet, we may say, "this is the case. This is also useful." Or we may say, "This is a simple thing, I never thought of it before ". It is precisely this kind of indifference and shaking that reflects the value of these arguments: they may have been over-emphasized, exceeded, and deprecated theoretically, but even so, in practice, we often ignore these basic principles. For us, MMM may be the first book about attitude. The first problem identified by it is the attitude towards software development. It is precisely because of an attitude that we are keen on finding a silver bullet to solve all the problems (such as the RUP, CMM, and XP/Agile) and never earnestly implementing any of these principles; we are so anxious to put one feature after another in the system, ignoring the actual effect of the user's use; we cannot believe that we can form a "surgical" team, developers who do not design products cannot be found; we will accept monthly adjustments for various people and finally bring projects into the tar pit ".

In my opinion, software engineering is a kind of slow art first. In this process, planning, communication, meditation, and iteration account for a large proportion. Similarly (if not more important), misplacement, repetition, and even digress should also have a place. Even if the project's controllability is emphasized, it is difficult to exclude these necessary steps (remember the French restaurant example ?). What we can do is to give them enough time and patience (You know I am not referring to conniving at the extension ).

The two time ratios proposed by Brooks in the book may be worth noting: A "ready to run" program will become a programming product) it takes three times the programming time; likewise, it takes three times the time for programs to become program systems. If this happens, you need to get the programming systems product, which is a bit of a programming interface, but think about it carefully ?), It takes nine times to write a program that can be converted. In addition, when talking about schedule planning, he said that 1/3 of the total schedule is allocated to planning, 1/6 encoding (coding ), 1/4 component test and early system test, and the last 1/4 system test.

Similar division is far more rough than the "milestones" in our common methodologies. However, how many people believe that coding accounts for only 1/6 or even 1/9 of the total construction period? Is it because of our "attitude" that we are not able to work slowly? Can we name this attitude "impetuous? Can you stick to "1" when all competitors promise to complete the entire project with only that 1/6? Can we transition from one attitude to another like improving the realm of Qigong? Is software development a qigong? Does surgery, silver bullet, and French food all use Qigong? Can a werewolf be cured with Qigong? Can Qigong use monthly estimates? Who is more like a werewolf than an old bat? Will the werewolf be impetuous? Do an impetuous werewolf need Qigong or silver bullet more? Or book reviews? A bean-style book review?

Conclusion

Here, I would like to introduce the origins of this MMM. Open the book cover and I can see the words "Low Price Edition (LPE) authorized for sales only in India, Bangladesh, Pakistan, Nepal, Sri Lanka and Maldives" in the back cover. I don't know when the label of the original Bookstore (I remember "Graham, 250rs") fell off. However, even if this label is missing, just "LPE" still reminds me of the rush evening at the Graham bookstore in Bangalore: the third or fourth layer is the technology zone-I initially found only the OOSE Of The Babson (somewhat confused by the complicated bookstore layout) -- I saw the Software Project release Val Guide in another person's hand -- I turned to a clerk for help. He immediately gave me the book and an MMM -- the other clerk saw them and handed in another eagleware...

The completion of this article is mainly related to my accidental reading. It is related to the enthusiasm and conjecture of some friends on MMM in some forums, and may be indirectly related to the release of the Chinese version of the book. I have no intention of making any advertisement for this translation (I have talked about my attitude towards Chinese translation elsewhere), and of course I have no intention of making any anti-advertisement. However, if I do not have this book (an unfortunate assumption), I will go to the bookstore to flip the translation, let's look at the quality of illustration replication (especially those copper prints-LPE can help me count the hairs on the claw), and check whether there are comments and indexes after reading the book. There are still external and superficial factors that determine whether or not to purchase, just like the author of any bean-style book reviews.

References

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 pp

Peopleware: Productive Projects and Teams, 2nd Ed., by Tom Demarco, Timothy R. Lister, 1999 Dorset House, 264 pp

Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar jacbson et al, 1992 Addison-Wesley, 524 pp

Bean: The Movie, by Mel Smith (Director), 1997, 90 mins
-- The end