Liu Tianbei
October 2002 THE Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 PP
From the dimensions, Mr. Bean is a "painter's portrait of the painter", the first thing to talk about: "QUITE BIG, so it can't afford". This kind of criticism, the ancient Chinese is already: "The tea is praised" hot "is that it is. Today we talked about Brooks' "THETHICAL MAN-MONTH" (Chinese translation as "Moon Myth", the next referred to as MMM), also in the UK experts, from the size: a prominent advantage of this book, smaller. There are two points, one is open, one is the number of pages. Nietzsche said that my ambitions have been used in ten sentences. I can say clear things (he added a sentence - or even, a book is unclear). However, for the publishing industry, such a wild heart is not going. Most book director, or because of the many shortcomings involved, it can always be played with the French: he has no time to write in a short. Short writing is not what everyone can do, this requires good insecurity and structural sense - it is difficult to find qualities in a hurry IT from the industry. It is a general technical book, mostly a high horse, and has a high-rise, and there is also a customary practice of domestic photocopy. It is printed into a small brother, but considering the additional reading difficulty, the result is not imagined. ). "Big", for books - especially technical books, not necessarily "gone". Taking my personal reading habits, more than 500 pages, open the technology monographs of "big 32 open", then only as a dictionary, and a big palace in the palace, even if it is tonally, if you want three Thousands of pets love set, don't think it is. I have been in the hands, there is a soft and jade, I always be "light", "thin" is wonderful, if it is a huge giant, the body wolf is unable to make psychological barriers (with this corner to read "C PRIMER, gauge: You can do "big internal and emotional zero zero" royal emperor). This MMM, which is said, is the technical book, which can make the handheld dance: the big 32 open, count the annotation, the index is 332 pages, it is tightly, the large number of spaces in each chapter are left Questions and topics, 19 chapters, there is less than 200 pages. If you decide to read this book, you may be able to make a time budget with my personal experience: not for a fixed reading plan, but to murder the boring time on the morning bus, I have selected this appearance, a lot of illustrations MMM (its predecessor seems to be the long pass of the Sleep of the sleeves).
On Sunday afternoon before the week, I hit the third chapter of the book: "The MMM After 20 Years"), the author's famous single papers "no silver bullet" and "again There is no silver bullet refired "; after this, the following chapters of the following chapters are approximately distributed in the 5th and 2 chapters of the speed in the 5th car. (About 35 each time) Untire 40 minutes, I have been sitting at the station); Finally, a sleeping eye is on Saturday morning, I have completed the rest - I can't believe that this "leisure" reading form is applicable to any other technology "Famous" (may be "peopleware", we will talk about it in a while) - maybe you will bring this "Planning XP" to you tomorrow? .
Delicious analysis, in addition to small, what is the benefit of this book? Yes, then it is better to read. I read the book is purely "take people", the appearance is everything (the French said: the skin is the most profound part of the person). Just like the meal, "delicious" is good, nutrition, etc. In my generation, or the second righteousness, but for the intention of "spiritual food", "good reading" should also be the highest in the book. approval. I read two layers, read it is easy, and read it. The small book is not easy to read (I heard "logic philosophy"?), Easy-to-read books are not all! It is easy to read, but it seems like children cough syrup, it is more intelligence to you. Insult - Is there a teacher?) But for a technical note, it is clear, and it is also a great achievement. Some people wrote the book, one flavor in the "inner beauty", I don't know, "accessibility" is the first ring: We don't say "delicious", "can be"? " "Can" (also Ability in Accessibility) is the most important. Back to the topic, talk about the structure of the book: I have the MMM's twenty-year commemorative version (Anniversary Edition), a total of 19 chapters (also short quotation - the primary version and the re-version - and end). Among them, Chapters 1 to 15 are the first edition content, the longest chapter 17 pages, the shortest chapter fifth chapter planing questions and topics, but thin thin two half sheets. The author said that these chapters are "Essays", each handle each other dealing with independent themes ("Month" problem, the personnel of the software project, the exchange of communication, documentation, tired, etc.), so you can basically Don't take into account the link between the chapters, start with any paragraphs you interested in any paragraphs. In the four chapters of the book, Chapter 18, "proposition of mmm: True or false?" Is a list of all views of each chapter - a very easy to check and warm, other three chapters (for "silver bombs "Two discussions and postscripts) The space is 20 to 40, which is worth dedication. For a technical book in a preliminary version, the author did not revise the original content, and the selection of the remarks was selected, and the report was lost in accordance with the technical and understanding of the technical and understanding of the postscript. Now, you can probably see this book: very thin, turn over to each chapter, and contain a large number of whole pages (see the color black and white from the side of the page). In other words, readability is first from the appearance, you pick it up, and you will feel delicious now. Then you will notice the style of the book. Regarding the language style of the original technology, I have done another difference: readable / translated (the feet imitation of another pair of French concepts). "Readable" style is mainly written in a writer written in native language. They can use the elements in the language, almost always find the most appropriate expression for specific concepts. These expressions are often rooted in the language itself, so it is difficult to convert to another language. For example, the author of this book gives the title of "Ten Pounds in Five-Pound Sack". For any readers with college entrance examination English, it means very intuitive, but who can easily give it Chinese equivalent? "Sharperse"? (I happen to know that the translation is so translated.
) "Five pounds of sacks 10 pounds"? On the other hand, "translated" text is mostly the product of immigrant writers. For a concept, they lack "nature" expression. They are placed in the same way as someone else's language, a string of furniture. You can simply translate such text, and you can even use machine translations without making big mistakes (from Jacobson et al. Casual sentence: "When STRONG SEMANTICS Are Provided At The Behavioral Description Level for All of these Fundamental Issues , "), but no matter whether it is translated or not translated, it is difficult to understand what he is talking about. Of course, this can only be the most simplified 0 order simulation on the actual situation (some local writers who like to join slang in the text cannot be classified). However, when I said "readable", I first thought about Brooks and another master Martin Fowler. The styles of the two have a lot of common: kind, do not sell, can use the most common English description (sometimes to make our Chinese desperate) complex problems. The author brooks of this book (maybe "Small" Brooks is right, because his full name is "Fredrick P. Brooks, Jr."), which has served as IBM's large machine System / 360 and its operating system OS / 360 The development project manager, known as "S / 360 Father", after which it is transferred to the university, and it is difficult to have a world-class level in the actual project management and teaching. After leaving IBM for nearly ten years (1975), he wrote this book based on a large number of small practices and teaching experience, in style, and both teachers 'mellow patience and engineers' technical qualities. I personally benefit from the wonderful metaphor from the book. Just mention a few examples: "tar", "Cathedral", "Surgery Team", "Silver Bomb", forget that almost every one is the most appropriate to the object that is the object. The brilliance of these metaphors, throughout the number of questions, the title (sometimes no humor) reflection, gains the effect of shining. In many cases, excessive pursuit of "humorous" also produces a cough syrup. A typical example is Peopleware. Compared with MMM, the book always gives me a salesman's textbook. 2 Book Author's technical background (I don't think Demarco has participated in serious software projects), and the difference between the religious background (Brooks is a devout Christian) may explain the gap between the sale and the simple, empty, and thick.
Enlightenment from French restaurants, surgery tables and isrs, let us review the practice of beans himself. In my opinion, it has a formalist feature that is difficult to recognize: mainly considering "external", form (such as painting size) elements, and ignoring the actual reproducible content of the work - We remember the only mention of Peas The wording of the old lady in the painting: stopped in the cactus, ugly old bat ("A Hideous Old Bat Who Looks Like She's Got A Cactus Lodged Up Her Backside"). Do I also use this strategy? Readers (I envision, most of you who see this book review is technical expert) I am afraid that I will buy a bead, and the content of MMM is also much more visible than "old bat". Even so, the views in the exam letter are also unrealistic: First, no one is worse than the author has been done, if you do need, it is better to see Chapter 18 of the original book; second, the book does not have a consistent The central idea can be extracted, for example, communication, documentation, tired, tool and other fields, each worthy of a copyable discussion. After considering, I decided to talk about the content that I can't think about the original book. "This is also the essence of the essence of my bus reading practice (essentially a high-pass filtering process).
The month is the first is "Man-Month". Everyone familiar with the software project management is clear, people often estimate the workload (and payable accordingly) according to people's months, such as five people completed in two months, then the total workload is 10 people. This book is named, and the term "Moon Myth" can be said to "Moon Myth" is a "album". In addition to the second chapter of the title, there is no much content related to this. It is called "myth", the author's intention is not completely negative as the month of the metering method, but to clarify the influences implied in this concept. According to my diligent, unreliable memory, the main arguments here include: 1. People / month cannot be converted, in other words, the two have been completed for five months, and it can be completed in two months. (It is also the most controversial point) increasing people in the post-project period, only further postponed during the period; 3. The greater the project, the more people needed by the unit work. Alternatively, in return, the author wants to smash the myth of the "Month" concept. Whether it is the number of developers, or the change in workload, it can lead to a non-linear change of the final completion time. The author's dramatic expression is: adding manpower to a late software project Makes it even laverage. This point is in fact not like it seems so provocative, and the author is in the first version and posts, which means that this contains reasonable exaggeration. Even in a further study, increasing people do not necessarily delaying the construction period, but will definitely reduce the efficiency of the project - and if you must increase your hand, you will be better. It is concluded that the main consideration is to increase the implicit cost of the human hand (the communication cost of personnel training, multi-person working) and the incomparable crucial path in the project process (CRUCIAL PATH). For project management, this should be a truth that is self-evident. However, due to the pressure of the final decision makers, there is often a case where it is in violation of this violation. The author put a formal restaurant menu into the book as a question, I also recommend the sentence on the menu: FAIRE de la Bonne Cuisine Demande Un certin temps. Si On Vous Fait Attendre, C'est Pour Mieux Vous Servir ET VOSS PLAIRE (for a good time. If people let you wait for you, it is to make you finally eat happy.) For French customers / bosses, this will be a good impression.
Conceptual Integrity If you must find the concept of throughout the book, "Conceptual Integrity" may be a one. I would rather add some feature of seven seven eight eight (Anomalous Features), should also be guaranteed that the entire system reflects the complete set of design philosophy: this is the meaning of introducing conceptual integrity. The beneficiaries of concept integrity include end users, system developers, trainers, and service staff. The conceptual integrity keeps a good system more easily, requiring shorter training time and learning time, and it is also easier to develop. However, in the practice of software production, decision makers at all levels can easily produce the tendency to emphasize "function" and neglect concept integrity. Therefore, we have seen too much contain a large number of "functions", and the overall system does not know the clouded system, and there are too many times due to one or two additional functions to delay, and even the abstore. Therefore, the author puts forward that conceptual integrity is the most important consideration in system design. In all aspects of guaranteeing conceptual integrity, I think the author is most interesting. First, to overcome the "The Second System Effect" of the system. When a system designer is designed to design the first edition system, it is often considered to be considered by weaker self-confidence and strength, and it will try to cut the number of functions to achieve. When the first edition system is successfully released, when the second edition design is started, with the enhancement of self-confidence, a large number of previously pressed proposals will be reproduced, and the designer will not be so conservative when it is stuffed into new features. This is likely to lead to a bloated and lack of conceptual integrity of the second edition system (the author's 1995 Example is Windows NT after Windows 31). Second, the effective organization of the entire project team helps to ensure concept integrity. First, you must distinguish between product personnel and developers, Architect and Implementer. The Architect manager here is equivalent to the general product manager. Only some of him and a few people can determine the entire product demand, and should not leave even the finest demand to developers. In the process of demand determination, repeated repeated, including feedback from developers is necessary, but to ensure conceptual integrity, it must be a minority, or even a person. In addition, "surgery" development team can be considered in development, that is, by the only "Surgist" (technology big) and multiple assistants, testers, contact personnel, document / tool / configuration administrator, secretary The team made up. Obviously, whether it is product / developer's distinction, or the introduction of surgery teams, core principles are 1) function segmentation; 2) Putting high requirements in a few people. In fact, the author said in other chapters, one of the best ways to improve the quality of the software project is to find the right person. The difference between "great" designer and ordinary designer is larger than the difference between any advanced tool / method / management mode.
Silver bombs and other additional "silver bombs" in the additional part is another concept of authors. In the ancient wolf legend, only silver bullets can uniform these foressenger monsters. Therefore, the author also uses the word "silver" and naming people's long-wrapped monsters of the uniform software project. "No silver bomb" means that there is no way (regardless of technical or management), you can take advantage of its existing software development and productivity (reliability / simpleness) in order. The author's argument is simple and (in my opinion) is effective: the difficulties of software development come from two aspects: essential and accidental (similar to the essential / donating opposition in the philosophy of the hospital). The difficulty of essence is that software development itself is inherent, unable to cancel any way, and accidental difficulties are in which non-intrinsic factors can be eliminated by introducing new tools, methodology or management models. The key is that as long as the essential difficulties consume ten percent workload in software development, it is impossible to increase the productivity 10 times even if all eliminating casual difficulties.
Just like a lot of other demonstraits of the author. After reading some of the silver bombs, we or will say "this is the case, this is also said", or will say "such a simple thing, how did I not think before." It is this rocking between relief and shocks embodying the value of these arguments: they may have been in theory that it is already over-emphasized, being surpassed, was spurred, but even so, in practice, we tend to be these Basic principles will be completely desperate. For us, MMM may be a book about attitude. It is the first that it should take advantage of how to take software development work. It is because of some kind of attitude, we will be passionate about the silver bomb to solve all problems (RUP is good, CMM is also good, XP / Agile is also good) and will implement any of these principles sincerely; we will rush to In the system, it is a functional effect when it is ignores the actual effect when the user is used; we will not believe that you can form a "surgical style" team, you can't find developers who don't do product design; we will once again Accept the shape of the moon, finally brought one project into the "tar". According to my opinion, the software engineering is the first of all a slow art. In this middle, planning, communication, meditation, and iterative have a large proportion, the same (if it is not more important), misplaced, repeated or even the issue should also be a place. Even emphasizing the controllability of the project, it is also difficult to exclude these necessary links (remember the examples of French restaurants?). What we can do is to give them enough time and tolerance (you know that I don't mean the concession). Brooks proposed in the book may be paying attention to: a "transy to run" program (Program) to become a program product requires 3 times the programming time; the same, can turn Program becomes a program system (Programming System) also requires 3 times. This will be obtained, you have to get the program system product (Programming Systems Product - a bit of mouth, but think about it, can you?), 9 times the time to write "can turn" program. In addition, he said in the period of time planning, one-third of the entire construction period, two-thirds, quarter component test and early system test (Component Test and Early System Test) ), The last quarter system test. Similar division, far more rough than the "milestone" in various methodologies we are, how many people believe that coding should only account for one-third of the entire construction period in practice? Is it still "attitude" causes us to lose slow work? Can we name this attitude as "impetuous"? When all competitors have promised to complete the entire project with only one-sixth, can you adhere to the "one"? Can we enlighten to enhance the realm of Qigong to another? Is software development a kind of Qigong? Are surgery, silver bombs and french dishes? Can the wolf be cured with Qigong? Can Qigong estimated by people? Bean and old bats, who is more like a waswolf? Wolf will be impetuous? Is the impetuous wolf need not Qigong or a silver? Still book review? A bean bean book review?
The end of the end is here, I am willing to introduce my hand of this MMM. Open book skin, I can see the word "LOW Price Edition (LPE) Authorized for Sales Only in India, Bangladesh, Pakistan, Nepal, Sri Lanka and Maldives. The original bookstore label (I am impressive "Graham, 250RS") I don't know when I fall off. But even if this label is lacking, only "LPE" can still let me recall the hasty dusk spent on the Graham Bookstore of Bangalore: The third or four layers are the technical area - I started to find Jacobson's OOSE (a bit confusing In complex bookstores layout) - See another person's Software Project Survival Guide - I asked for a clerk, he immediately gave me the book, and a mmm - another clerk saw them, Come into a PeopleWare ... This article is completed, mainly related to my accidental reading, and some friends in the forum are related to MMM's enthusiasm, and the Chinese version of the book may only have indirect relationships. I have no intention to make any ads for this translation (I talked else to talk about the attitude of Chinese translation), of course, more unintentional advertisements. However, if there is no such thing in the hand now (an unfortunate hypothesis), I will go to the bookstore to turn over the translation, see the quality of the drawing copy (especially those copper paintings - LPE can make my black wolf's foot claws ), Have any comments and indexes after reading the book. Still is those outside, superficial factors will determine if I bought, just like the author of any bean book review. References * The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley * Peopleware: Productive Projects and Teams, 2nd Ed, by Tom Demarco, Timothy R. Lister. , 1999 Dorset House * Object-Oriented Software Engineering: a Use Case Driven Approach by Ivar Jacobson et al, 1992 Addison-Wesley * Bean: The Movie, by Mel Smith (Director), 1997
