小弗雷德里克·P.布鲁克斯(Frederick P. Brooks, Jr.1931—2022),图灵奖得主、美国国家科学院院士,对计算机体系结构、操作系统和软件工程做出里程碑式贡献的计算机科学家。
布鲁克斯博士于20世纪60年代初主持与领导了被称为人类从原子能时代进入信息时代的标志的IBM/360系列计算机的开发工作,取得辉煌成功,被认为是“IBM 360系统之父”。布鲁克斯博士创立了北卡罗来纳大学的计算机科学系,并于1965—1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。
布鲁克斯博士作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上,因其专业成就和对计算机体系结构的卓越贡献而屡获表彰,包括美国国家技术奖、ACM杰出服务奖、ACM Fellow、ACM Newell奖、IEEE McDowell奖、计算机先驱奖、冯·诺伊曼奖、富兰克林学会鲍尔奖、图灵奖等。
目錄:
Chapter 1 The Tar Pit 001
Chapter 2 The Mythical Man-Month 009
Chapter 3 The Surgical Team 023
Chapter 4 Aristocracy, Democracy, and System Design 033
Chapter 5 The Second-System Effect 045
Chapter 6 Passing the Word 053
Chapter 7 Why Did the Tower of Babel Fail? 065
Chapter 8 Calling the Shot 079
Chapter 9 Ten Pounds in a Five-Pound Sack 089
Chapter 10 The Documentary Hypothesis 097
Chapter 11 Plan to Throw One Away 105
Chapter 12 Sharp Tools 115
Chapter 13 The Whole and the Parts 127
Chapter 14 Hatching a Catastrophe 139
Chapter 15 The Other Face 149
Chapter 16 No Silver Bullet—Essence and Accident in Software
Engineering 165
Chapter 17 “No Silver Bullet” Refired 195
Chapter 18 Propositions of The Mythical Man-Month: True or False? 219
Chapter 19 The Mythical Man-Month after 20 Years 245
Epilogue285
Notes and References 287
內容試閱:
Preface to the
First Edition
In many ways, managing a large computer programming project is like managing any other large undertaking—in more ways than most programmers believe. But in many other ways it is different—in more ways than most professional managers expect.
The lore of the field is accumulating. There have been several conferences, sessions at AFIPS conferences, some books, and papers. But it is by no means yet in shape for any systematic textbook treatment. It seems appropriate, however, to offer this little book, reflecting essentially a personal view.
Although I originally grew up in the programming side of computer science, I was involved chiefly in hardware architecture during the years (1956—1963) that the autonomous control program and the high-level language compiler were developed. When in 1964 I became manager of Operating System/360, I found a programming world quite changed by the progress of the previous few years.
Managing OS/360 development was a very educational experience, albeit a very frustrating one. The team, including F. M. Trapnell who succeeded me as manager, has much to be proud of. The system contains many excellencies in design and execution, and it has been successful Preface to the First Edition
in achieving widespread use. Certain ideas, most noticeably deviceindependent input-output and external library management, were technical innovations now widely copied. It is now quite reliable, reasonably efficient, and very versatile.
The effort cannot be called wholly successful, however. Any OS/360 user is quickly aware of how much better it should be. The flaws in design and execution pervade especially the control program, as distinguished from the language compilers. Most of these flaws date from the 1964—65 design period and hence must be laid to my charge. Furthermore, the product was late, it took more memory than planned, the costs were several times the estimate, and it did not perform very well until several releases after the first.
After leaving IBM in 1965 to come to Chapel Hill as originally agreed when I took over OS/360, I began to analyze the OS/360 experience to see what management and technical lessons were to be learned. In particular, I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development. This book is a belated answer to Tom Watson’s probing questions as to why programming is hard to manage.
In this quest I have profited from long conversations with R. P. Case, assistant manager 1964—65, and F. M. Trapnell, manager 1965—68. I have compared conclusions with other managers of jumbo programming projects, including F. J. Corbató of M.I.T., John Harr and V. Vyssotsky of Bell Telephone Laboratories, Charles Portman of International Computers Limited, A. P. Ershov of the Computation Laboratory of the Siberian Division, U.S.S.R. Academy of Sciences, and A. M. Pietrasanta of IBM.
My own conclusions are embodied in the essays that follow, which are intended for professional programmers, professional managers, and especially professional managers of programmers.
Although written as separable essays, there is a central argument contained especially in Chapters 2—7. Briefly, I believe that large programming projects suffer management problems different in kind from small ones, due to division of labor. I believe the critical need to be the preservation of the conceptual integrity of the product itself.
These chapters explore both the difficulties of achieving this unity and methods for doing so. The later chapters explore other aspects of software engineering management.
The literature in this field is not abundant, but it is widely scattered.
Hence I have tried to give references that will both illuminate particular points and guide the interested reader to other useful works. Many friends have read the manuscript, and some have prepared extensive helpful comments; where these seemed valuable but did not fit the flow of the text, I have included them in the notes.
Because this is a book of essays and not a text, all the references and notes have been banished to the end of the volume, and the reader is urged to ignore them on his first reading.
I am deeply indebted to Miss Sara Elizabeth Moore, Mr. David Wagner, and Mrs. Rebecca Burris for their help in preparing the manuscript, and to Professor Joseph C. Sloane for advice on illustration.
Chapel Hill, N.C. F. P. B., Jr
October 1974