該**中強調由於軟體的複雜性本質，而使真正的"銀彈"並不存在；所謂的"沒有銀彈"是指沒有任何一項技術或方法可使軟體工程的生產力在十年內提高十倍。好了, 看看這篇**摘要.
所有軟體創作都包括了本質性工作（essential task）和附屬性工作（accidental task）。前者是去創造出一種由抽象的軟體實體所組成的複雜概念結構，後者則是用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言。
現在，若跟本質性的工作相比，軟體工程人員所做的事，還有多少算是花在附屬性的工作上呢？除非附屬性工作要耗費的心力超過全部工作的9/10，否則就算是將所有的附屬性工作降至零，也無法將整個開發工作的輕鬆程度提公升乙個數量級。
因此，似乎是時候解決軟體任務的本質性部分了，這部分涉及形成非常複雜的抽象概念結構。我建議:
- 開拓大眾市場，避免構建可以購買的東西。
- 在建立軟體需求時，將快速原型(rapid prototyping)作為計畫迭代的一部分。
- 有組織地增長軟體，為系統增加越來越多的功能執行，使用和測試。
- 確定並培養新一代的優秀概念設計師。
從個人在公司開發軟體的經驗, 我們過去兩三個月以及更多的時間, 都在修復舊的bug和優化原先的功能缺陷. 試想如果每個軟體開發者都是認真負責的, 那整個專案的生產力會在乙個新的台階上.正因為我們的**庫里存在太多不負責的**, 這些**大多並不是--程式設計技術上的bug(容易發現, 並且容易修正), 而是--實現上的敷衍(不容易發現, 並且不容易修正).如果在程式設計時只是為了完成任務, 並沒有為自己的**抱有認真負責的態度, 那麼這樣的**將在後續的維護和迭代公升級中造成災難.
引用王垠在《怎樣尊重乙個程式設計師》的一段話
如果你明白我在說什麼，從今天起就對自己的**負起責任來，不要再讓其它人修補自己的bug，不要再修補其他人的bug當我持有這樣的觀點時, 我就開始覺得《人月神話》這本書沒有讀下去的必要性了, 因為我們關注軟體開發的側重點截然不同.
軟體開發的質量紅線
質量紅線是我的乙個客戶提出的概念，即質量管理的底線 最低要求 最低標準，無論在什麼情況下，專案都不能違背這個底線，比如專案組在進行多快好省四個要素平衡時，無論如何平衡，都不能違背質量的最低要求。我認為這個名詞很直觀形象，因此借用一下。在定義質量紅線時應該從質量的投入與質量的產出兩個方面進行定義。質量...
軟體測試 VS 軟體開發
對於 軟體測試與 軟體開發之間的關係，一直以來都很微妙，大型 制度健全的公司或許不那樣明顯但在中小型 制度尚不健全的公司，則變成為了老大難的問題。軟體需求 軟體開發 軟體測試是軟體公司技術部門的三大主力，今天我們要說的是軟體開發與軟體測試。軟體開發與軟體測試即是乙個統一體，也是乙個矛盾體。為什麼說他...
程式設計師的生產力
剛剛看到一篇文章，說是好的程式設計師生產力是普通程式設計師的幾倍，甚至上百倍。文章是乙個台灣人寫的 對裡面關於 工具 和 自動化 的描述，有了一些新的領悟，故記錄於此。公司總是在強調，完成本職工作，只是meet，如果想exceed some 或是 exceed most，一定要有創新思維或者積極主動...