這是人月神話：軟體專案管理之道（20週年紀念版）的第四章：專制、民主與系統設計，在The Introduction of The Surgical Team有提到概念整體性的問題，文章之前展示蘭斯主教座堂跟其他教堂的不同處，來說明系統設計應該保有概念整體性(conceptual integrity)。
達成概念整體性
『只有當功能增強所節省下來的時間超過學習、記憶和查閱手冊所耗費的時間，電腦的使用便利性(ease of use)才會提昇，以現代軟體工程來說，這方面的確是獲益大於所付出的成本，但最近幾年，似乎是複雜的功能越加越多，而獲益成本比(ratio of gain to cost)卻隨之越低。』這真的是如此，電子產品功能太多不見得是好事，我妹的朋友就因此把新買的HTC手機讓給我用，因為他連電腦都不太會用，導致他買了智慧型手機之後，竟然不會用，有時人會為趕流行買下新奇的東西，但是如果不夠便利使用的話，很快地在垃圾桶中找到它。
『由於目的是使用便利性，所以功能概念複雜度比(ratio of function to conceptual complexity)才是系統設計的最終測試標準，好的設計既不可單獨偏重功能性，也不可偏重簡單性。』
這個功能概念複雜度比術語看起來就很複雜，我不知是否有計算公式可以計算，但是正如作者說的，就是要兼顧功能性、便利性、簡單性(simplicity)，所以簡單地講就是要直接(straightforwardness)，就像我從我妹朋友拿來這隻HTC Touch Diamond來說好了，它的外觀很炫很酷，操作也很像Windows，就手機的功能使用來說也很多，可以就簡單性來說，我覺得比不上Nokia的，使用也不夠直接，常常一個功能不知到哪找，害我去日本還不能導航，迷路浪費了不少時間，真是令人嘔！
專制與民主
『要達成概念整體性，換句話說，這意味設計必須出自於一個人的想法，或是極少數人的一致決定。
然而，時程的壓力卻迫使系統的開發工作必須由更多人來一起合作，有兩個技術可以用來解決這兩難的問題。第一個是小心地把工作切分成架構(architecture)與實作(implementation)兩部份，第二個就是上一章所提到的外科手術團隊。…這裡的架構指的是使用者介面完整而詳細的規格。…實作是講如何具體實現(realization)』，比如最近我接了一個案子，一個部門的主管要我將別的部門的交接簿拿來用，請我幫他做，但是我因為另一個部門的伺服器環境的不同，不想照抄他的程式碼，而且我也不想破壞這個主管原有的習慣性，所以我照抄他的架構，也就是介面的部份，但是我在實作時，已經把他把所有的程式語言都改掉了，但是使用者卻感覺不出差異來，接著我就可以繼續擴展我的程式功能，如此我才可以繼續在這一家公司待下去。
這裡所說的專制與民主，就好像架構與實作，看起來好像要專制一點，而架構因此看起來就比較重要，所以相形之下架構設計師好像比較偉大，但是作者還是有反駁，說『實作上的設計工作跟制定外部規格(external specification)相比，不見得就是沒有創意的工作，只是發揮創意的類型不同罷了』，看到讓ㄚ琪好像稍微寬心一點了，看起來還是有揮灑的空間。而且實際上，『產品的成本效能比(cost-performance ratio)是非常仰賴實作人員才能夠提昇的，這跟使用便利性得仰賴架構設計師的道理一樣的。』
約束對藝術而言是件好事 (discipline is good for art)這個不知是哪裡的典故，但是dejavu這樣說『當我們常常在抱怨，生活有太多的限制，使我們無法充分的發揮專長時，是否有想過。出名的藝術家，總是在嚴苛的環境中，製作了永垂不朽的名作。過去的我曾經天真的以為，不朽的生命可以為世界帶來進步。但慢慢地，我體悟到，一個人的成就不在於生命的長短。反而容易因為生命的無止盡，使得我們終日怠惰、荒廢。印象中曾經有一個（或許不止一個）漫畫家，將未來（人類擁有幾乎無止盡的生命）描繪成一個地獄，因為生命可以隨意製造，所以人類再也不尊重生命了。 』這樣子的想法對比於『形式就是解放(form is liberating)』，看起來也是對比的，善與惡、對與錯、黑與白這種對比的概念，一定讓人很頭痛，就連孔子講得中庸，我看就更難了，所以怎樣拿捏，我看到這裡，還沒搞清楚，所以就繼續看吧！
在架構完成之前，實作人員要做些什麼？
看起來好像沒事可做，因為如果架構沒有先完成，由實作人員來先做專案那麼會發生很多災難，雖然實作人員一定會有反對的理由，因為這樣會少賺很多薪水，但是這些理由，作者都一一地解釋並不成為問題，另外實作人員也不用怕沒事做，其實事情還是很多的，要怎麼做，就端賴領導者的能力吧。
最後作者做這樣的結論，『要達成概念整體性，真的是有賴於讓系統反映出單一的理念，使用者介面的規格必須出於少數人的構想。雖然將人力切分為架構設計、實作和實現三部份，但並不意味這麼做就會花掉更多的時間，由經驗可知剛好相反，整個系統的設計不但進行更快，而且花在測試的時間會比較少。效果是，垂直分工將大幅減輕水平分工所產生的負擔，其結果也將大幅簡化溝通，並且增進概念整體性。』