Brooks, Fredrick P., “No Silver Bul

Brooks, Fredrick P., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, Vol 20, No 4 (April 1987), pp. 10-19

This is the famous article by Brooks which Cockburn referred to in Agile Software Development. In it, Brooks defines some concepts relating to software development in order to help people see what makes software development hard in an effort (possibly) to dissuade people from believing that there is yet to be a silver bullet which will make software development easy enough for anyone to do well. He says there are two classes of qualities of software: essential qualities, and accidental qualities. The essential qualities are extremely difficult to address or improve, while the accidental qualities can be improved via tool support.

The essential qualities all have to do wth the design of software: understanding the problem and designing and testing the conceptual contstruct. The accidental qualities have to do with implementing the construct in code and testing it.

The essential qualities are these:

Complexity: software design is complex: understanding domain concepts to the extent that one can define them and the relationships between them exactly is hard; this definition is essential if we want to translate those concepts into code. Unlike physical objects, no two parts of a software construct are alike. Scaling up of a software entity necessarily means a scaling up in components and complexity. The problem associated with complexity are: difficulty of communication of design among team members; difficulty in enumerating all possible states of the program (which brings unreliability); makes programs hard to use; makes programs hard to change without inducing unwanted side-effects. The complexity makes overview hard (seeing and tying up loose ends), and the tremendous learning burden means turnover is costly.
Invisible: can’t see it all at once as you would a physical piece of something. It is also very difficult even to visualize since there are many ways to look at the same design: “the reality of software is not inherently embedded in space.” This inhibits communication of structure and design.
Changeable: we’re just pushing bits around in the end; changing ideas. Therefore it is always possible to change a piece of software. Software is inherently flexible where physical products are not. (McConnell , pp. 19-20). Change comes in two ways: people use the software in ways not originally forseen in the design and want better support for that; and the physical machine/OS changes underneath us.
Conformity: software must conform to external constraints (particular hardware, legacy systems and data, regulations) that make it difficult to reduce complexity. Much of the complexity of interacting with human systems is arbitrary, and since software is percieved as changeable, it is most often seen as the thing which should conform, not the human system.
The accidental qualities are all about implementation and testing, and these have been solved almost as well as they are likely to be solved, so don’t expect many more breakthroughs. Here are things that Brooks says have helped to reduce the impact of the accidental qualities (keep in mind he’s writing this in the middle of the 1980s):

High level languages (including object orientation). High level languages allow programmers to express implementation with concepts closer to that which we use in design. We’re reducing or eliminating the translation step between data models, operations, sequances and communication and registers and bits. This eliminates a lot of the translation complexity. But Brooks says that “the most a high-level language can do is to funish all the constructs that the programmer imagines in the abstract program” and although our level of thinking about those constructs is improving, it does so at an ever decreasing rate.
Time sharing and better OS support: Time sharing is contrasted with batch processing, and it helps because we spend much less time in the code and test cycle. By better OS support, I mean the difference betweeen DOS (which has no library and almost no system call support) and UNIX (which contains many libraries and a vast system call set, allowing you to not have to implement display code, disk drivers, filesystems code, etc.).
He then talks about hopes for the future, and discounts all as being silver bullets: Ada and other high-level languages, object orientation, AI (both in the idea of software solving problems that were previously the domain of human intelligence; and in expert systems), expert systems, automatic programming (we specify the requirements and the software writes code for us); graphical programming (a la LabVIEW), proof based design verification, better tools, and workstations.

He identifies three promising areas that may help promote obtaining (note: not necessarily building) better software:

Buy versus build. Remember that in the mid 1980s, the software market was still small.
Incremental, iterative development with feedback from end users: because this helps to refine requirements, prove the design, and improves morale
Identify, retain and coddle great designers: some people are just better at software design than others. Try to identify them, retain them in your organization, and coddle them so that they get the skills and compensation that they need.

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

Brooks, Fredrick P., "không có đạn bạc: bản chất và tai nạn của công nghệ phần mềm," máy tính, Vol 20, số 4 (tháng 4 năm 1987), trang 10-19Đây là bài viết nổi tiếng bởi Brooks Cockburn được gọi nhanh nhẹn phát triển phần mềm. Trong đó, Brooks xác định một số khái niệm liên quan đến phát triển phần mềm để giúp mọi người nhìn thấy những gì làm cho phát triển phần mềm cứng trong một nỗ lực (có thể) để ngăn cản người từ tin rằng có chưa được một viên đạn bạc mà sẽ làm cho phát triển phần mềm dễ dàng, đủ cho bất cứ ai để làm tốt. Ông nói có hai lớp học của các phẩm chất của phần mềm: phẩm chất cần thiết, và phẩm chất do tai nạn. Những phẩm chất cần thiết là vô cùng khó khăn để địa chỉ hoặc cải thiện, trong khi những phẩm chất tình cờ có thể được cải thiện thông qua công cụ hỗ trợ.Những phẩm chất cần thiết tất cả phải làm wth thiết kế phần mềm: sự hiểu biết vấn đề và thiết kế và thử nghiệm đều khái niệm. Những phẩm chất tình cờ có để làm với việc thực hiện xây dựng trong mã và thử nghiệm nó.Những phẩm chất thiết yếu là đây:Phức tạp: thiết kế phần mềm là phức tạp: hiểu biết về khái niệm miền đến mức mà một trong những có thể xác định họ và các mối quan hệ giữa chúng chính xác là cứng; định nghĩa này là điều cần thiết nếu chúng tôi muốn dịch các khái niệm đó vào mã. Không giống như các đối tượng vật lý, không có hai phần của một xây dựng phần mềm là như nhau. Mở rộng của một tổ chức phần mềm nhất thiết có nghĩa là một rộng lên trong thành phần và phức tạp. Vấn đề liên quan đến phức tạp: khó khăn trong giao tiếp của thiết kế trong số thành viên trong nhóm; khó khăn trong liệt kê tất cả các nước có thể của chương trình (mà mang lại không đáng tin cậy); làm cho chương trình khó sử dụng; làm cho chương trình khó có thể thay đổi mà không gây ra tác dụng phụ không mong muốn. Sự phức tạp làm cho tổng quan cứng (nhìn thấy và ràng buộc lên kết thúc lỏng), và gánh nặng to lớn học tập có nghĩa là doanh thu là tốn kém.Vô hình: không thể nhìn thấy nó tất cả cùng một lúc như một mảnh vật lý của một cái gì đó. Nó cũng là rất khó khăn thậm chí để hình dung kể từ khi có rất nhiều cách để nhìn vào thiết kế tương tự: "thực tế của phần mềm không vốn đã nhúng trong không gian." Điều này ức chế giao tiếp của cấu trúc và thiết kế.Thay đổi: chúng tôi đang chỉ cần đẩy bit xung quanh thành phố cuối cùng; thay đổi ý tưởng. Do đó ta luôn luôn có thể thay đổi một phần của phần mềm. Phần mềm là hơi linh hoạt mà sản phẩm vật lý là không. (McConnell, trang 19-20). Thay đổi đi kèm theo hai cách: người sử dụng phần mềm theo cách không được forseen trong thiết kế và muốn tốt hơn hỗ trợ cho điều đó; và những thay đổi vật lý máy/OS bên dưới chúng ta.Sự phù hợp: phần mềm phải phù hợp với bên ngoài khó khăn (đặc biệt phần cứng, Hệ thống kế thừa và dữ liệu, quy định) mà làm cho nó khó khăn để giảm độ phức tạp. Phần lớn sự phức tạp của tương tác với hệ thống con người là tùy ý, và kể từ khi phần mềm là percieved như thay đổi, nó thường được coi là điều mà nên phù hợp, không có hệ thống của con người.Những phẩm chất do tai nạn là tất cả về việc thực hiện và thử nghiệm, và những đã được giải quyết gần như cũng như họ có khả năng được giải quyết, vì vậy đừng mong đợi nhiều bước đột phá thêm. Đây là điều mà Brooks nói đã giúp để giảm tác động của những phẩm chất do tai nạn (lưu ý ông văn bản này vào giữa thập niên 1980):Cao cấp ngôn ngữ (bao gồm cả đối tượng định hướng). Ngôn ngữ cấp cao cho phép lập trình để nhận thực hiện với khái niệm gần gũi hơn để mà trong đó chúng tôi sử dụng trong thiết kế. Chúng tôi đang giảm hoặc loại bỏ bước dịch giữa dữ liệu mô hình, hoạt động, sequances và giao tiếp và đăng ký và bit. Điều này loại bỏ rất nhiều phức tạp dịch. Nhưng Brooks nói rằng "nhiều nhất một ngôn ngữ cấp cao có thể làm là để funish tất cả các cấu trúc các lập trình viên tưởng tượng trong chương trình trừu tượng" và mặc dù mức độ chúng tôi suy nghĩ về xây dựng những đang cải thiện, nó như vậy tại một tỷ lệ giảm bao giờ.Thời gian chia sẻ và tốt hơn hỗ trợ hệ điều hành: thời gian chia sẻ tương phản với xử lý hàng loạt, và nó giúp bởi vì chúng tôi chi tiêu ít thời gian trong chu kỳ mã và thử nghiệm. Bởi hỗ trợ hệ điều hành tốt hơn, tôi có nghĩa là sự khác biệt Hội DOS (trong đó có thư viện không và hầu như không có cuộc gọi hệ thống hỗ trợ) và UNIX (mà có chứa nhiều thư viện và một hệ thống rộng lớn gọi thiết lập, cho phép bạn không cần phải thực hiện Hiển thị mã trình điều khiển đĩa, Hệ thống tập tin mã, vv.).Ông sau đó nói về Hy vọng cho tương lai, và giảm giá tất cả là bạc đạn: Ada và ngôn ngữ cấp cao khác, đối tượng định hướng, AI (cả trong ý tưởng của phần mềm giải quyết vấn đề mà trước đây tên miền của trí tuệ con người; và trong hệ thống chuyên gia), chuyên gia hệ thống, tự động lập trình (chúng tôi xác định các yêu cầu và các phần mềm viết mã cho chúng tôi); đồ họa lập trình (a la LabVIEW), bằng chứng dựa trên xác nhận thiết kế, công cụ tốt hơn và máy trạm làm việc.Ông xác định ba lĩnh vực đầy hứa hẹn có thể giúp thúc đẩy việc thu thập (lưu ý: không nhất thiết phải xây dựng) tốt hơn phần mềm:Mua so với xây dựng. Hãy nhớ rằng trong giữa thập niên 1980, thị trường phần mềm là vẫn còn nhỏ.Phát triển gia tăng, lặp đi lặp lại với thông tin phản hồi từ người dùng cuối: bởi vì điều này sẽ giúp để tinh chỉnh các yêu cầu, chứng minh thiết kế, và cải thiện tinh thầnXác định, Giữ lại và coddle nhà thiết kế tuyệt vời: một số người chỉ tốt hơn lúc thiết kế phần mềm hơn những người khác. Cố gắng để xác định chúng, Giữ lại chúng trong tổ chức của bạn, và coddle họ để cho họ có được các kỹ năng và bồi thường mà họ cần.