軟體專案在時程緊迫的情況下，如果專案範圍、期限與資源不可能更動，常有些人會認為要達成專案目標，應該減少軟體設計的時間，增加程式實作的時間。這些人以為時間緊迫，沒有時間做設計，軟體設計對軟體專案產出的頁獻不是最直接的，還不如把節省設計的時間拿來寫程式。誠如M君在矇矇的秘密基地的《軟體的模組化(Modulize)設計應該要徹底實踐！》中提到～
這就是現實的問題，有專案在身上的時候，就很難做到。只有沒有專案的情形下才能真正落實，沒有專案就是要花錢，事實上我們老闆只是把上個專案賺的錢決定不要再接著賺，不是很有錢（我們手上有了三個專案都是10M以上的，全都暫時用政治力量擱置），要落實真的流程，當然目的是想未來能否賺更多錢。
M君的觀點看起來似乎是理所當然，但大多數的專案的經驗及教訓(Lesson Learn)卻告訴我們：「忽略軟體設計的專案難逃專案失敗的命運」。如果我們因應專案時間緊縮而在早期不做設計或整體規劃，到專案後期會因為不做設計所引發的高度風險而以失敗收場。為什麼為這樣呢？因為我們落入了「捨本逐末」的系統陷阱中 閱讀全文
最近克明兄在《軟體的模組化(Modulize)設計應該要徹底實踐！》的主題討論中特別提到～
Process Definition 是與 Workflow 核心分離的。各位可以以此來審視國內的 Workflow 產品，是否有哪一套產品確實可以做到這一點，這還只是 Interface-1 而已喔。
其實國內的workflow engine廠商都聲稱符合WfMC工作流程標準，但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式，所得到的答案多半是「客製化」這個專業術語，但進一步了解才發現，他們並未設計界面來做為減震點(Decouple Point)以減少不必要的模組相依，而是模組必須和特定的實作緊密耦合在一起，也就是他們的客製化會使原先定義良好的模組被破壞了。因此可以推知他們並不是採用模組分離的設計，也就是並未符合所謂的模組鬆散耦合的理想。我想這當中除了作業環境會有不相容的問題外(Web base vs. AP base)，更重要的原因就是市場利基的考量，技術問題容易克服的，但workflow市場恐怕還沒具備須鬆散耦合設計的條件。 閱讀全文
軟體開發比一般的產品開發還要困難，一開始使用者並不清楚他們所需要的軟體需求，所以也無法告訴軟體設計者，而這些需求也很難預測出來，同時還有需求變動的風險。
因此，針對需求的不確定，軟體設計的方式應該做一些調整。 閱讀全文
詹姆斯．雷非爾(james redfield)在《聖境新世界》中提到了人是一種能量場，而在人與人的互動當中，當兩人把注意力集中在對方的身上時，他們的能量場就會融合，能量也就會開始匯集。那麼這匯集的巨大能量該由誰來控制？若其中一方能凌駕於一方之上，迫使對方接受他的觀點，並用他的眼光來看這世界，則他便能將這些能量據於已有，而會感到無比亢奮、安全及滿足，也會感到無比的幸福、快樂。
然而，另一個能量被擷取的一方，便會因為被對方犧牲而感到手足無措、焦慮不安、渾身虛脫，彷佛體內的能量剎時之間都流失了。他們通常的反應便是把失去的能量搶回來，必要時不惜任何代價。而這種相互競爭搶奪的現象，雷非爾先生把它們稱為控制戲，並把控制戲區分為四種類型，包括乞憐者、冷漠者、審問者及脅迫者。
控制戲會削弱我們的心靈能量，讓我們不斷想從對方身上獲取能量，而造成彼此間永無休止的痛苦。所以當我們認清這些戲碼的劇本時，我們可以選擇不使控制戲來削弱我們的力量。接下來我們從占星學的角度，由四大元素的分類來了解控制戲的能場與星座性格的關係。 閱讀全文
記得當初跟隨老師學太極拳時，老師常跟我們講忽靈勁，看老師表演得出神入化，但刻意去練卻怎麼也得不到要領。老師只教我們先學完整套拳架再練勁，等我們練完的拳架以後才發現，在我們招式熟悉後，體會到放鬆，勁道就自然出來了。正如太極拳論所言：由招熟而漸悟懂勁，由懂勁而「階」至神明。軟體設計開發，又何嘗不是如此。
軟體開發就如同練拳一樣，程式實作就相當於招式，一招一式好像是理所當然；但設計技巧如何，因人而異，面對相同問題，每個人可能會有不一樣的設計手法，程式寫得愈多，對設計愈有不同的體會，如果你對程式如何解決問題沒有深切的體認，很難設計出彈性及功能兼具的系統。 閱讀全文
