No Silver Bullet—Essence and Accide

No Silver Bullet
—Essence and Accident in Software Engineering
Frederick P. Brooks, Jr.
University of North Carolina at Chapel Hill
There is no single development, in either technology or management
technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in simplicity.
Abstract
1
All software construction involves essential tasks, the fashioning of the complex
conceptual structures that compose the abstract software entity, and accidental tasks, the
representation of these abstract entities in programming languages and the mapping of
these onto machine languages within space and speed constraints. Most of the big past
gains in software productivity have come from removing artificial barriers that have
made the accidental tasks inordinately hard, such as severe hardware constraints,
awkward programming languages, lack of machine time. How much of what software
engineers now do is still devoted to the accidental, as opposed to the essential? Unless it
is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not
give an order of magnitude improvement.
Therefore it appears that the time has come to address the essential parts of the
software task, those concerned with fashioning abstract conceptual structures of great
complexity. I suggest:
Exploiting the mass market to avoid constructing what can be bought.
•
Using rapid prototyping as part of a planned iteration in establishing software
•
requirements.
Growing software organically, adding more and more function to systems as they are
•
run, used, and tested.
Identifying and developing the great conceptual designers of the rising generation.
•
Introduction
Of all the monsters who fill the nightmares of our folklore, none terrify more than
werewolves, because they transform unexpectedly from the familiar into horrors. For
these, we seek bullets of silver than can magically lay them to rest.
Reproduced from: Frederick P. Brooks,
The Mythical Man-Month, Anniversary edition with 4 new
1
chapters
, Addison-Wesley (1995), itself reprinted from the
Proceedings of the IFIP Tenth World
Computing Conference
, H.-J. Kugler, ed., Elsevier Science B.V., Amsterdam, NL (1986) pp. 1069-76.

F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986)
2
The familiar software project has something of this character (at least as seen by the
non-technical manager), usually innocent and straightforward, but capable of becoming a
monster of missed schedules, blown budgets, and flawed products. So we hear desperate
cries for a silver bullet, something to make software costs drop as rapidly as computer
hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no
single development, in either technology or management technique, which by itself
promises even one order of magnitude improvement in productivity, in reliability, in
simplicity. In this chapter we shall try to see why, but examining both the nature of the
software problem and the properties of the bullets proposed.
Skepticism is not pessimism, however. Although we see no startling breakthroughs,
and indeed, believe such to be inconsistent with the nature of software, many
encouraging innovations are under way. A disciplined, consistent effort to develop,
propagate, and exploit them should indeed yield an order-of-magnitude improvement.
There is no royal road, but there is a road.
The first step toward the management of disease was replacement of demon theories
and humours theories by the germ theory. That very step, the beginning of hope, in itself
dashed all hopes of magical solutions. It told workers the progress would be made
stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a
discipline of cleanliness. So it is with software engineering today.
Does It Have To Be Hard? – Essential Difficulties
Not only are there no silver bullets now in view, the very nature of software makes it
unlikely that there will be any-no inventions that will do for software productivity,
reliability, and simplicity what electronics, transistors, and large-scale integration did for
computer hardware. We cannot expect ever to see twofold gains every two years.
First, we must observe that the anomaly is not that software progress is so slow but
that computer hardware progress is so fast. No other technology since civilization began
has seen six orders of magnitude price-performance gain in 30 years. In no other
technology can one choose to take the gain in either improved performance or in reduced
costs. These gains flow from the transformation of computer manufacture from an
assembly industry into a process industry.
Second, to see what rate of progress we can expect in software technology, let us
examine its difficulties. Following Aristotle, I divide them into essence-the difficulties
inherent in the nature of the software-and accidents-those difficulties that today attend
its production but that are not inherent.
The accidents I discuss in the next section. First let us consider the essence.
The essence of a software entity is a construct of interlocking concepts: data sets,
relationships among data items, algorithms, and invocations of functions. This essence is
abstract, in that the conceptual construct is the same under many different
representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing
of this conceptual construct, not the labor of representing it and testing the fidelity of the
representation. We still make syntax errors, to be sure; but they are fuzz compared to the
conceptual errors in most systems.

F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986)
3
If this is true, building software will always be hard. There is inherently no silver
bullet.
Let us consider the inherent properties of this irreducible essence of modern software
systems: complexity, conformity, changeability, and invisibility.
Complexity.
Software entities are more complex for their size than perhaps any other
human construct, because no two parts are alike (at least above the statement level). If
they are, we make the two similar parts into one, a subroutine, open or closed. In this
respect software systems differ profoundly from computers, buildings, or automobiles,
where repeated elements abound.
Digital computers are themselves more complex than most things people build; they
have very large numbers of states. This makes conceiving, describing, and testing them
hard. Software systems have orders of magnitude more states than computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same
elements in larger size; it is necessarily an increase in the number of different elements.
In most cases, the elements interact with each other in some nonlinear fashion, and the
complexity of the whole increases much more than linearly.
The complexity of software is in essential property, not an accidental one. Hence
descriptions of a software entity that abstract away its complexity often abstract away its
essence. Mathematics and the physical sciences made great strides for three centuries by
constructing simplified models of complex phenomena, deriving properties from the
models, and verifying those properties experimentally. This worked because the
complexities ignored in the models were not the essential properties of the phenomena. It
does not work when the complexities are the essence.
Many of the classical problems of developing software products derived from this
essential complexity and its nonlinear increased with size. From the complexity comes
the difficulty of communication among team members, which leads to product flaws, cost
overruns, schedule delays. From the complexity comes the difficulty of enumerating,
much less understanding, all the possible states of the program, and from that comes the
unreliability. From the complexity of the functions comes the difficulty of invoking those
functions, which makes programs hard to use. From complexity of structure comes the
difficulty of extending programs to new functions without creating side effects. From the
complexity of structure comes the unvisualized state that that constitute security
trapdoors.
Not only technical problems but management problems as well come from the
complexity. This complexity makes overview hard, thus impeding conceptual integrity.
It makes it hard to find and control all the loose ends. It creates the tremendous learning
and understanding burden that makes personnel turnover a disaster.
Conformity.
Software people are not alone in facing complexity. Physics deals with
terribly complex objects even at the “fundamental” particle level. The physicist labors
on, however, in a firm faith that there are unifying principles to be found, whether in
quarks or in unified field theories. Einstein repeatedly argued that there must be
simplified explanations of nature, because God is not capricious or arbitrary.
No such faith comforts the software engineer. Much of the complexity he must
master is arbitrary complexity, forced without rhyme or reason by the many human

F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986)
4
institutions and systems to which his interfaces must confirm. These differ from interface
to interface, and from time to time, not because of necessity but only because they were
designed by different people, rather than by God.
In many cases the software must confirm because it has most recently come to the
scene. In others it must conform because it is perceived as the most conformable. But in
all cases, much complexity comes from conformation to other interfaces; this cannot be
simplified out by any redesign of the software alone.

Kết quả (Việt) 1:

Không có đạn bạc— Bản chất và tai nạn trong công nghệ phần mềmFrederick P. Brooks, Jr.Đại học North Carolina tại Chapel HillCó là có sự phát triển duy nhất, công nghệ hoặc quản lýkỹ thuật, mà tự nó hứa hẹn thứ tự độ lớn ngay cả mộtcải thiện trong vòng một thập kỷ năng suất, độ tin cậy, trong đơn giản.Tóm tắt1Tất cả phần mềm xây dựng liên quan đến tác vụ chủ yếu, fashioning khu phức hợpkhái niệm cấu trúc soạn trừu tượng phần mềm thực thể và tác vụ do tai nạn, cácđại diện của các thực thể trừu tượng trong lập trình ngôn ngữ và lập bản đồ củachúng lên máy ngôn ngữ trong không gian và tốc độ hạn chế. Phần lớn của quá khứ lớntăng năng suất phần mềm đã đi từ việc loại bỏ các rào cản nhân tạo mà cóthực hiện các nhiệm vụ do tai nạn đang khó khăn, chẳng hạn như những hạn chế nghiêm trọng phần cứng,vụng về ngôn ngữ lập trình, thiếu máy thời gian. Bao nhiêu những gì phần mềmkỹ sư bây giờ do là vẫn dành cho tình cờ, như trái ngược với tinh? Trừ khi nólà nhiều hơn 9/10 của tất cả nỗ lực, thu hẹp lại tất cả các hoạt động tình cờ đến thời gian không sẽ khôngcung cấp cho một sự cải tiến đơn đặt hàng của các cường độ.Do đó nó xuất hiện có thời gian để giải quyết các bộ phận thiết yếu của cácphần mềm công việc, những người có liên quan với fashioning trừu tượng khái niệm cấu trúc củaphức tạp. Tôi đề nghị:Khai thác thị trường đại chúng để tránh việc xây dựng những gì có thể được mua.•Bằng cách sử dụng prototyping nhanh chóng như là một phần của kế hoạch lặp trong việc thiết lập phần mềm•yêu cầu.Phát triển phần mềm hữu cơ, bổ sung chức năng hơn và nhiều hơn nữa để hệ thống như bọn chúng•chạy, được sử dụng, và thử nghiệm.Xác định và phát triển các nhà thiết kế khái niệm tuyệt vời của các thế hệ tăng.•Giới thiệuTất cả các quái vật người điền vào những cơn ác mộng của văn hóa dân gian của chúng tôi, không có terrify nhiều hơnngười sói, bởi vì họ biến bất ngờ từ quen thuộc vào nỗi kinh hoàng. Chonày, chúng tôi tìm kiếm đạn bạc hơn kỳ diệu có thể đẻ họ nghỉ ngơi.Sao chép từ: Frederick P. Brooks,Mythical Man-Month, Anniversary edition với 4 mới1chương, Addison-Wesley (1995), bản thân tái bản từ cácThủ tục tố tụng của thế giới IFIP xMáy tính hội nghị, H. J. Kugler, ed., khoa học Elsevier B.V, Amsterdam, NL (1986) trang 1069-76. F. Brooks: Không có đạn bạc — tinh túy và tai nạn trong công nghệ phần mềm (1986)2Dự án phần mềm quen thuộc có một cái gì đó của nhân vật này (ít nhìn thấy bởi cácGiám đốc kỹ thuật), thường vô tội và đơn giản, nhưng có khả năng trở thành mộtcon quái vật bị mất lịch trình, thổi ngân sách và hoàn thiện sản phẩm. Vì vậy, chúng tôi nghe tuyệt vọngkhóc cho một viên đạn bạc, một cái gì đó để làm cho phần mềm chi phí giảm nhanh chóng máy tínhchi phí phần cứng làm.Tuy nhiên, như chúng ta nhìn đường chân trời của một thập kỷ vì thế, chúng ta thấy không có đạn bạc. Có không cóđơn phát triển, công nghệ hoặc quản lý kỹ thuật, mà tự nóhứa hẹn ngay cả một đơn đặt hàng của các cường độ cải thiện năng suất, trong độ tin cậy, trongđơn giản. Trong chương này, chúng tôi sẽ cố gắng để xem lý do tại sao, nhưng kiểm tra cả hai bản chất của cácvấn đề phần mềm và các thuộc tính của viên đạn được đề xuất.Chủ nghĩa hoài nghi không phải là bi quan, Tuy nhiên. Mặc dù chúng tôi thấy không có bước đột phá đáng ngạc nhiên,và thực sự, tin rằng như vậy là không phù hợp với bản chất của phần mềm, nhiềukhuyến khích đổi mới được theo cách. A xử lý kỷ luật, các nỗ lực phù hợp để phát triển,tuyên truyền, và khai thác chúng nên thực sự mang lại một sự cải tiến đơn đặt hàng của cường độ.Không có đường Hoàng gia, nhưng đó là một con đường.Bước đầu tiên hướng tới việc quản lý bệnh là thay thế của lý thuyết con quỷvà humours lý thuyết của germ theory. Rằng bước rất, sự khởi đầu của hy vọng, trong chính nótiêu tan hy vọng tất cả các giải pháp huyền diệu. Nó nói với người lao động trình sẽ được thực hiệnsau, tại nỗ lực rất lớn, và rằng một chăm sóc liên tục không ngớt đã có thể được trả cho mộtkỷ luật của sạch sẽ. Do đó, nó là với công nghệ phần mềm vào ngày hôm nay.Nó có để khó khăn? -Những khó khăn khái quátKhông chỉ là có không có đạn bạc bây giờ trong chế độ xem, bản chất của phần mềm làm cho nókhông chắc rằng sẽ có bất kỳ không có phát minh rằng sẽ làm cho phần mềm năng suất,độ tin cậy, và đơn giản, điện tử, bóng bán dẫn và hội nhập large-scale những gì đã làm chophần cứng máy tính. Chúng tôi không thể mong đợi bao giờ để xem gấp đôi lợi nhuận mỗi hai năm.First, we must observe that the anomaly is not that software progress is so slow butthat computer hardware progress is so fast. No other technology since civilization beganhas seen six orders of magnitude price-performance gain in 30 years. In no othertechnology can one choose to take the gain in either improved performance or in reducedcosts. These gains flow from the transformation of computer manufacture from anassembly industry into a process industry.Second, to see what rate of progress we can expect in software technology, let usexamine its difficulties. Following Aristotle, I divide them into essence-the difficultiesinherent in the nature of the software-and accidents-those difficulties that today attendits production but that are not inherent.The accidents I discuss in the next section. First let us consider the essence.The essence of a software entity is a construct of interlocking concepts: data sets,relationships among data items, algorithms, and invocations of functions. This essence isabstract, in that the conceptual construct is the same under many differentrepresentations. It is nonetheless highly precise and richly detailed.I believe the hard part of building software to be the specification, design, and testingof this conceptual construct, not the labor of representing it and testing the fidelity of therepresentation. We still make syntax errors, to be sure; but they are fuzz compared to thekhái niệm sai sót trong hầu hết hệ thống. F. Brooks: Không có đạn bạc — tinh túy và tai nạn trong công nghệ phần mềm (1986)3Nếu điều này là đúng, xây dựng phần mềm sẽ luôn luôn được khó khăn. Đó là vốn không có bạcviên đạn.Hãy để chúng tôi xem xét các thuộc tính vốn có của này bản chất irreducible của phần mềm hiện đạiHệ thống: phức tạp, sự phù hợp, changeability, và tàng hình.Phức tạp.Tổ chức phần mềm là phức tạp hơn cho kích thước của họ hơn có lẽ bất kỳ kháccon người xây dựng, bởi vì không có hai phần là như nhau (ít mực tuyên bố). Nếuhọ đang có, chúng tôi thực hiện hai phần tương tự như làm một, một chương trình con, mở hoặc đóng cửa. Trong điều nàyHệ thống phần mềm tôn trọng sâu sắc khác nhau từ máy tính, tòa nhà, hoặc xe ô tô,nơi lặp đi lặp lại các yếu tố rất nhiều.Máy tính số là phức tạp hơn so với hầu hết những điều con người xây dựng; họcó số lượng rất lớn của tiểu bang. Điều này làm cho thụ thai, mô tả, và thử nghiệm chúngkhó khăn. Hệ thống phần mềm có đơn đặt hàng của các cường độ thêm kỳ so với máy tính.Tương tự như vậy, một mở rộng quy mô-up của một tổ chức phần mềm không phải là chỉ đơn thuần là một sự lặp lại của cùng mộtCác yếu tố kích thước lớn hơn; nó nhất thiết phải là sự gia tăng trong số lượng các yếu tố khác nhau.Trong hầu hết trường hợp, các yếu tố tương tác với nhau trong một số thời trang phi tuyến, và cácphức tạp của toàn bộ tăng tuyến tính nhiều hơn.Sự phức tạp của phần mềm là ở essential bất động sản, không phải là một tai nạn. Do đóMô tả của một tổ chức phần mềm đó tóm tắt đi phức tạp của nó thường trừu tượng đi của nóessence. Mathematics and the physical sciences made great strides for three centuries byconstructing simplified models of complex phenomena, deriving properties from themodels, and verifying those properties experimentally. This worked because thecomplexities ignored in the models were not the essential properties of the phenomena. Itdoes not work when the complexities are the essence.Many of the classical problems of developing software products derived from thisessential complexity and its nonlinear increased with size. From the complexity comesthe difficulty of communication among team members, which leads to product flaws, costoverruns, schedule delays. From the complexity comes the difficulty of enumerating,much less understanding, all the possible states of the program, and from that comes theunreliability. From the complexity of the functions comes the difficulty of invoking thosefunctions, which makes programs hard to use. From complexity of structure comes thedifficulty of extending programs to new functions without creating side effects. From thecomplexity of structure comes the unvisualized state that that constitute securitytrapdoors.Not only technical problems but management problems as well come from thecomplexity. This complexity makes overview hard, thus impeding conceptual integrity.It makes it hard to find and control all the loose ends. It creates the tremendous learningand understanding burden that makes personnel turnover a disaster.Conformity.Software people are not alone in facing complexity. Physics deals withterribly complex objects even at the “fundamental” particle level. The physicist laborson, however, in a firm faith that there are unifying principles to be found, whether inquarks or in unified field theories. Einstein repeatedly argued that there must besimplified explanations of nature, because God is not capricious or arbitrary.No such faith comforts the software engineer. Much of the complexity he mustmaster is arbitrary complexity, forced without rhyme or reason by the many human F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986)4institutions and systems to which his interfaces must confirm. These differ from interfaceto interface, and from time to time, not because of necessity but only because they weredesigned by different people, rather than by God.In many cases the software must confirm because it has most recently come to thescene. In others it must conform because it is perceived as the most conformable. But inall cases, much complexity comes from conformation to other interfaces; this cannot besimplified out by any redesign of the software alone.

Kết quả (Việt) 2:

Không Silver Bullet
-Essence và Tai nạn trong Software Engineering
Frederick P. Brooks, Jr.
Đại học North Carolina tại Chapel Hill
Không có phát triển duy nhất, trong cả hai công nghệ hoặc quản lý
kỹ thuật, mà bởi chính nó hứa hẹn thậm chí một trật tự-of-độ lớn
cải thiện trong vòng một thập kỷ về năng suất, độ tin cậy, trong sự đơn giản.
Tóm tắt
1
Tất cả các phần mềm xây dựng liên quan đến nhiệm vụ cần thiết, những chế tác phức tạp
cấu trúc tư tưởng mà soạn thực thể phần mềm trừu tượng, và các công việc tình cờ, các
đại diện của các thực thể trừu tượng trong ngôn ngữ lập trình và lập bản đồ của
các máy vào ngôn ngữ trong không gian và tốc độ hạn chế. Hầu hết các quá khứ lớn
lợi nhuận trong sản xuất phần mềm đã đi từ loại bỏ rào cản nhân tạo đã
thực hiện các nhiệm vụ tình cờ inordinately cứng, chẳng hạn như hạn chế phần cứng nghiêm trọng,
ngôn ngữ lập trình khó khăn, thiếu thời gian máy. Làm thế nào nhiều về những gì các phần mềm
kỹ sư bây giờ vẫn được dành cho việc tình cờ, như trái ngược với sự cần thiết? Trừ khi đó
là hơn 9/10 của tất cả nỗ lực, thu hẹp lại tất cả các hoạt động tình cờ để không có thời gian sẽ không
cung cấp cho một đơn đặt hàng cải thiện độ lớn.
Do đó nó xuất hiện mà đã có thời gian để giải quyết những phần thiết yếu của
nhiệm vụ phần mềm, những người có liên quan với fashioning cấu trúc khái niệm trừu tượng của đại
phức tạp. Tôi đề nghị:
Khai thác thị trường đại chúng để tránh xây dựng những gì có thể được mua.
•
Sử dụng mẫu nhanh như một phần của một sự lặp lại kế hoạch trong việc thiết lập phần mềm
•
yêu cầu.
Trồng phần mềm hữu cơ, thêm càng nhiều chức năng cho hệ thống khi chúng được
•
chạy, sử dụng, và thử nghiệm.
Xác định và phát triển các nhà thiết kế khái niệm to lớn của các thế hệ đang lên.
•
Giới thiệu
Trong tất cả những con quái vật đã lấp đầy những cơn ác mộng của văn hóa dân gian của chúng tôi, không khiếp sợ hơn
người sói, bởi vì họ biến đổi bất ngờ từ quen thuộc thành nỗi kinh hoàng. Đối với
những, chúng ta tìm kiếm những viên đạn bạc hơn kỳ diệu có thể đặt chúng để nghỉ ngơi.
Sao chép từ: Frederick P. Brooks,
The Mythical Man-Month, Anniversary edition với 4 mới
1
chương, Addison-Wesley (1995), tự in lại từ Proceedings của IFIP Tenth Thế giới Hội nghị Computing, H.-J. , Elsevier Science BV, Amsterdam, NL (1986) pp Kugler, ed.. 1069-1076. F. Brooks: Không Silver Bullet-Essence và tai nạn trong công nghệ phần mềm (1986) 2 Các dự án phần mềm quen thuộc cũng có một cái gì đó của nhân vật này (ít nhất là theo cách nhìn của các nhà quản lý không kỹ thuật), thường vô tội và đơn giản, nhưng có khả năng trở thành một con quái vật lịch trình bỏ qua, ngân sách thổi, và sản phẩm hoàn thiện. Vì vậy, chúng tôi nghe thấy tuyệt vọng tiếng kêu cứu cho một viên đạn bạc, một cái gì đó để làm cho chi phí phần mềm thả nhanh như máy tính chi phí phần cứng làm. Tuy nhiên, như chúng ta nhìn vào chân trời của một thập kỷ do đó, chúng tôi thấy không có viên đạn bạc. Không có phát triển duy nhất, trong cả hai công nghệ hoặc quản lý kỹ thuật, mà bởi chính nó hứa hẹn thậm chí một thứ tự cải thiện độ lớn về năng suất, độ tin cậy, trong sự đơn giản. Trong chương này, chúng tôi sẽ cố gắng để xem lý do tại sao, nhưng kiểm tra cả bản chất của các vấn đề phần mềm và các tính chất của những viên đạn được đề xuất. Chủ nghĩa hoài nghi không phải là bi quan, tuy nhiên. Mặc dù chúng tôi thấy không có những đột phá đáng ngạc nhiên, và quả thật, tin rằng như vậy là không phù hợp với bản chất của phần mềm, nhiều cải tiến đáng khích lệ đang được tiến hành. Một xử lý kỷ luật, nỗ lực nhất quán để phát triển, truyền bá và khai thác chúng thực sự nên năng suất được cải thiện trật tự của độ richter. Không có đường hoàng, nhưng có một con đường. Bước đầu tiên hướng tới việc quản lý của bệnh là sự thay thế của lý thuyết quỷ và humours lý thuyết của lý thuyết mầm bệnh. Đó là biện pháp rất, khởi đầu của hy vọng, tự nó tiêu tan mọi hy vọng của các giải pháp huyền diệu. Nó nói với nhân viên tiến độ sẽ được thực hiện từng bước, lúc nỗ lực tuyệt vời, và rằng một, chăm sóc không ngớt liên tục sẽ phải được trả cho một kỷ luật của sự sạch sẽ. Vì vậy, đó là với công nghệ phần mềm hiện nay. Điều đó có phải là khó? - Những khó khăn Essential Không chỉ có không có đạn bạc bây giờ trong quan điểm, chính bản chất của phần mềm làm cho nó không chắc rằng sẽ có bất kỳ-không có những phát minh đó sẽ làm cho sản xuất phần mềm, độ tin cậy và tính đơn giản những gì thiết bị điện tử, bóng bán dẫn, và quy mô lớn hội nhập đã làm cho phần cứng máy tính. Chúng tôi không bao giờ có thể mong đợi để xem tăng gấp đôi mỗi hai năm. Đầu tiên, chúng ta phải thấy rằng sự bất thường mà không phải là tiến trình phần mềm như vậy là chậm nhưng mà tiến bộ phần cứng máy tính là quá nhanh. Không có công nghệ khác kể từ khi nền văn minh đã bắt đầu đã thấy sáu đơn đặt hàng của các cường độ tăng giá hiệu suất trong 30 năm. Trong không khác công nghệ ai có thể chọn để có những lợi trong hoặc cải thiện hiệu suất hoặc giảm chi phí. Những lợi ích này chảy từ việc chuyển đổi sản xuất máy tính từ một ngành công nghiệp lắp ráp thành một ngành công nghiệp. Thứ hai, để xem những gì tiến độ chúng ta có thể mong đợi trong công nghệ phần mềm, chúng ta hãy xem xét những khó khăn của mình. Sau Aristotle, tôi chia chúng thành chất-những khó khăn vốn có trong bản chất của các phần mềm và tai nạn-những khó khăn mà ngày nay tham dự sản xuất của mình nhưng điều đó không phải là vốn có. Các vụ tai nạn tôi thảo luận trong phần tiếp theo. Đầu tiên chúng ta hãy xem xét bản chất. Bản chất của một thực thể phần mềm là một cấu trúc của lồng vào nhau khái niệm: tập hợp dữ liệu, các mối quan hệ giữa các hạng mục dữ liệu, thuật toán, và các viện dẫn các chức năng. Bản chất này là trừu tượng, trong đó các cấu trúc khái niệm đều nằm cùng nhiều khác nhau đại diện. Đó là dù sao chính xác cao và đa dạng về chi tiết. Tôi tin rằng phần cứng của phần mềm xây dựng được các đặc điểm kỹ thuật, thiết kế, thử nghiệm và các cấu trúc khái niệm này, không phải là lao động đại diện cho nó và kiểm tra độ trung thực của các đại diện. Chúng tôi vẫn còn làm cho các lỗi cú pháp, chắc chắn; nhưng họ là lông tơ so với các lỗi về khái niệm trong hầu hết các hệ thống. F. Brooks: Không Silver Bullet-Essence và tai nạn trong công nghệ phần mềm (1986) 3 Nếu điều này là đúng, xây dựng phần mềm sẽ luôn luôn được khó khăn. Vốn không có bạc đạn. Chúng ta hãy xem xét các đặc tính vốn có của bản chất không thể rút gọn này của hiện đại phần mềm hệ thống:. Phức tạp, phù hợp, hay thay đổi, và tàng hình. Complexity thực thể phần mềm phức tạp hơn cho kích thước của chúng có lẽ hơn bất kỳ khác xây dựng con người, bởi vì không có Hai phần này là như nhau (ít nhất là trên cấp độ báo cáo). Nếu có, chúng tôi làm cho hai bộ phận tương tự thành một, một chương trình con, mở hoặc đóng cửa. Trong này tôn trọng các hệ thống phần mềm khác nhau một cách sâu sắc từ các máy tính, các tòa nhà, hoặc xe ô tô,., Nơi yếu tố lặp đi lặp lại rất nhiều máy tính kỹ thuật số là tự phức tạp hơn so với hầu hết những người xây dựng; họ có số lượng rất lớn của các quốc gia. Điều này làm cho việc thụ thai, mô tả, và thử nghiệm chúng cứng. Hệ thống phần mềm có đơn đặt hàng của các cường độ nhiều quốc gia hơn các máy tính làm. Tương tự như vậy, một rộng-up của một thực thể phần mềm không chỉ đơn thuần là một sự lặp lại của cùng một nguyên tố có kích thước lớn hơn; nó hẳn là một sự gia tăng về số lượng các yếu tố khác nhau. Trong hầu hết các trường hợp, các yếu tố tương tác với nhau trong một số thời trang phi tuyến, và phức tạp của toàn bộ tăng nhiều hơn so với tuyến tính. Sự phức tạp của phần mềm là tài sản quan trọng, không phải là một một tai nạn. Do đó mô tả của một phần mềm thực thể trừu tượng đi phức tạp của nó thường là trừu tượng đi của nó bản chất. Toán học và khoa học vật lý có những bước tiến lớn cho ba thế kỷ bởi xây dựng các mô hình đơn giản của hiện tượng phức tạp, xuất phát từ tính chất các mô hình, và xác minh những đặc tính thực nghiệm. Điều này làm việc vì sự phức tạp bỏ qua trong các mô hình không phải là những đặc tính thiết yếu của các hiện tượng. Nó không hoạt động khi sự phức tạp là bản chất. Nhiều người trong số các vấn đề cổ điển của phát triển sản phẩm phần mềm có nguồn gốc từ này phức tạp cần thiết và phi tuyến của nó tăng lên với kích thước. Từ sự phức tạp đến khó khăn trong việc giao tiếp giữa các thành viên trong nhóm, dẫn đến sai sót của sản phẩm, chi phí vượt, chậm trễ tiến độ. Từ sự phức tạp đến khó khăn trong việc liệt kê, sự hiểu biết ít nhiều, tất cả các trạng thái có thể có của các chương trình, và từ đó đến sự không đáng tin cậy. Từ sự phức tạp của các chức năng đi kèm những khó khăn của cách gọi những chức năng, mà làm cho chương trình khó sử dụng. Từ phức tạp của cấu trúc đến các khó khăn trong việc mở rộng chương trình đến các chức năng mới mà không tạo ra tác dụng phụ. Từ phức tạp của cấu trúc đi kèm tình trạng unvisualized đó mà tạo an ninh trapdoors. Không chỉ là vấn đề kỹ thuật, nhưng vấn đề quản lý cũng đến từ sự phức tạp. Sự phức tạp này làm cho tổng quan cứng, do đó cản trở vẹn khái niệm. Nó làm cho nó khó khăn để tìm thấy và kiểm soát tất cả các đầu lỏng lẻo. Nó tạo ra những học to lớn và gánh nặng sự hiểu biết mà làm cho kim ngạch nhân viên một thảm họa. Sự phù hợp. Phần mềm người ta không đơn độc trong việc đối mặt phức tạp. Vật lý giao dịch với các đối tượng khủng khiếp phức tạp ngay cả ở cấp độ hạt "cơ bản". Nhà vật lý người lao động trên, tuy nhiên, trong một niềm tin vững chắc rằng có những nguyên tắc thống nhất được tìm thấy, cho dù trong quark hoặc trong lý thuyết trường thống nhất. Einstein liên tục lập luận rằng có phải được đơn giản hóa các giải thích về bản chất, bởi vì Thiên Chúa không phải là thất thường hoặc tùy ý. Không có đức tin như vậy an ủi các kỹ sư phần mềm. Phần lớn sự phức tạp, ông phải nắm vững là phức tạp tùy ý, ép buộc mà không vần điệu hay lý do của con người nhiều F. Brooks: Không Silver Bullet-Essence và tai nạn trong công nghệ phần mềm (1986) 4 tổ chức và hệ thống để mà giao diện của mình phải xác nhận. Có khác với các giao diện để giao tiếp, và theo thời gian, không phải vì cần thiết nhưng chỉ vì họ đã được thiết kế bởi những người khác nhau, chứ không phải bởi Thiên Chúa. Trong nhiều trường hợp các phần mềm phải xác nhận bởi vì nó đã gần đây nhất đến hiện trường. Trong những người khác nó phải phù hợp vì nó được xem như là phù hợp nhất. Nhưng trong mọi trường hợp, nhiều phức tạp xuất phát từ cấu tạo các giao diện khác; điều này không thể được đơn giản hóa ra bởi bất kỳ thiết kế lại phần mềm một mình.