看過我之前文章的人，可能會感覺到我對不加思考的所謂分享是持鄙視態度的，不管這種分享被冠以乾貨，經驗或者隨便什麼名字。不是說這類分享沒價值，而是說越是這類分享越適合具體問題，而不適合影響因素過多的事物，比如管理，比如文化，比如方法論，比如對軟件本質問題的認知。
我們當然可以到StackOverflow上分享某個問題的具體解決方法，因爲具體技術類問題只依賴於簡單的上下文；但我們真的可以用一種簡單問答的形式去解決管理、文化、方法論上的問題麼，顯然是不行的，這需要一種更系統的思考，也就是我之前經常提到的特殊到一般，一般再到特殊的過程。但在具體思考解決問題前，其實還有個事情要做，你要對問題的載體有所認識，對IT人，問題的載體幾乎一定是軟件，那麼也就等價於需要對軟件的本質有所認識。
這就是上面的題目的來源，在忙於解決具體問題的同時：誰還願意談談軟件開發的本質？
本質問題的思考往往不作用於當下，而只對未來產生潛移默化的影響，當然也可能沒等產生影響，當事人就失去了所有機會。它的關鍵價值在於可以幫助一個人形成屬於自己的方法論。軟件是個很奇妙的東西，更像每個人都在橫看成嶺側成峯狀態的東西，所以很容易大家都自我感覺良好，看別人大大的不對，這時候要想不只侷限在怎麼解決一個Bug，就要思考一點本質的問題。
軟件的本質是什麼
爲了嚴密一點，我一般這麼描述軟件的本質：
軟件是一種固化的思維，這一點決定了許多的事情。從特質上來看，既然軟件是固化的思維，那就必然同時具備思維以及思維所承載之物之特質。
- 思維的特質是指：思維的澄清通常是漸進的，思維自身是不可度量的，思維的主體一定是人，思維通常由概念和邏輯組成，思維的無邊界化（靈活易變）這樣的特質。這部分特質是共通部分，同時屬於所有軟件。
- 思維承載之物之特質是指：當思維的對象是數學的時候，思維本身也就具備了數學的特質；當思維的對象是商業邏輯的時候，思維自身也就具備了商業邏輯的特質。
既然思維自身的特質是複合的，那麼作爲固化思維的軟件，其特質必然也是複合的：
既有屬於所有軟件的共同特質，也有特屬於某類軟件，甚至同其他類軟件完全相反的獨有特質。
---《完美軟件開發:方法與邏輯》
這也就意味着在軟件這一大的範疇裏，兩種矛盾的說法同時成立，並不是什麼值得驚訝的事情。只要思維承載的東西蘊含着彼此對立的東西，那麼兩種對立的觀點同屬於軟件這一範疇，並且同時爭取，一點也不稀奇。這很可能是大家吵來吵去的一個根本原因，因爲我們總是喜歡用自己的經歷來定義軟件是什麼以及判斷標準，但如果這種經歷來自完全不同的兩個領域，並且互相矛盾，那就只能吵架。實際上只有基於軟件是一種思維這樣特質推導出來的東西才更有普適性。
在什麼時候對本質的思考會有用
簡單來講越處理全局性長期性問題的時候，對本質的認知越能起點作用；而越是眼下就用類型的工作對本質問題的思考越沒什麼幫助。
比如：有個Bug讓程序崩潰了，而程序明天就用，最好的方法可能還是趕緊調試，而不是思考什麼本質。
但當我們要思考怎麼讓一個方法論落地更適合自己的時候，對本質的思考就能起點作用。比如始終會有公司會嘗試按Bug數和代碼行來度量一個人的績效。如果結合對本質問題的思考，一般來講就不會做這類決定。
對人進行量化管理的基石是：量化後的數字主要受個人表現這一個因素的影響，否則將產生巨大的不公正，並對個人工作意願產生不良影響，是真正的事與願違。
好比說，不同的工人在同等條件下生產杯子，一個人一小時生產5個，一個人1小時生產6個，那顯然後者要好於前者。這時，5和6可以用來比較的前提是兩個人的生產條件相同，比如生產工藝等。在這種情況下，量化後的數字爲個人表現的函數，因此量化管理基本上是公正的。
這時可以進一步來考慮下面的情形：兩個人同時生產杯子，廠方安排一個人用工藝a，另一個人用工藝b，這個時候前者一小時生產5個，後者1小時生產6個。這個時候單純比較5和6事實上是不公平的，因爲這1個杯子的差距可能是工藝造成的。
大多時候，軟件的情況比後一個情形還要糟糕一些。在軟件開發中，往往既沒有辦法清楚的界定一個人的輸入，也沒辦法清楚的界定一個人的輸出。
軟件開發的輸入是需求，對需求自身的複雜程度眼下來看還只能依賴判斷，而不能精確度量，現實中並沒有一種有效方法用以度量需求。
軟件開發的輸出是代碼，而代碼自身屬於固化後的思維。在度量思維時，多少、大小、長短、厚薄這類慣常的度量方向，並不具有多大意義。就好比說，不能講一個人代碼寫的越多貢獻就越大一樣。
誠然思維的表現形式是可以度量的，我們可以通過頁數來度量一本書的厚薄，通過分鐘來度量一部電影的長短，通過代碼行來度量軟件，但這種度量所反映的內涵是有限度的，精度也是有限度的。最終結果很可能是人員之間的差距是由誤差或其他非主觀因素造成的，而不是由個人工作好壞所造成的。
總結來看，在軟件開發中，數字含義的模糊性會導致使用數字進行評價包含非常多的不公正，這種不公正會對工作意願構成致命傷害，所以個人層面的量化管理在軟件開發面前，幾乎必然崩潰。
如果有這類思考和認知，想必做某些決定的時候正確性會稍微提高一點吧。
本質決定成敗還是細節決定成敗
這世上同時存在着兩種對立的聲音：本質決定成敗和細節決定成敗。偏好本質的人喜歡說本質論。偏好細節的人則喜歡說精細化管理。但如果在較長的時間軸上考量這兩種觀點，就會發現他們之間並不真的對立。
本質決定大尺度時間上的走勢和必然性，而細節則決定差異（包括短期成敗）。比如說：人的本質特徵是能思考，有一個頭，會衰老，壽命有限等，但區別不同人卻不是這些，而是性格，膚色，髮色等細節。
具體來看：軟件本質上是隻有人才能處理的東西，因此公司中程序員羣體的衰落一定會導致軟件自身的衰落，只有優秀的程序員羣體，才能保證軟件的持久成功，這是必然性。但優秀的程序員卻不一定確保當前項目成功，任何人在細節上的小疏忽，都可能導致軟件在市場上崩潰，死鎖，進而導致災難性後果，這就是細節決定成敗。
成敗自身雖然萬衆矚目，對個體而言卻只是一種偶然和機巧。當事人可以很努力的平衡本質上的追求（長期視點）和細節上的追求（短期視點），但變更的始終是一種成敗可能性。
