所有軟體創作都包括了本質性工作（essential task）和附屬性工作（accidental task）。前者是去創造出一種由抽象的軟體實體所組成的複雜概念結構，後者則是用程式設計語言來表現這些抽象的實體，并在某些空間和速度的限制之下，将程式對應至機器語言。
現在，若跟本質性的工作相比，軟體工程人員所做的事，還有多少算是花在附屬性的工作上呢？除非附屬性工作要耗費的心力超過全部工作的9/10，否則就算是将所有的附屬性工作降至零，也無法将整個開發工作的輕松程度提升一個數量級。
以往，軟體生産力的重要進展絕大部分是來自于人為障礙的排除，像是嚴苛的硬體限制、難用的程式設計語言、上機時間（machine time）的不足等等，這些都是造成附屬性工作益發困難的原因。
- 複雜性（complexity）：軟體要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智能活動，多半是複雜的。
- 隐匿性（invisibility）：尚未完成的軟體是看不見的，即使利用圖示說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。
- 配合性（conformity）：在大型軟體環境中，各子系統的接口必須協同一緻。由于時間和環境的演變，要維持這樣的一緻性通常十分困難。
- 易變性（changeability）：軟體所應用的環境常是由人群、法規、硬體裝置、應用領域等，各因素所彙集而成，而這些因素皆會快速變化。
大泥球（Big Ball of Mud）
1. 定義：
大泥球是指一個随意化的雜亂的結構化系統，隻是代碼的堆砌和拼湊，往往會導緻很多錯誤或者缺陷。
2. 缺點：
無法使得系統内的資訊得到更好的控制和共享，使得資訊失去了應有的價值。大泥球般的系統的整體結構沒有得到很好的界定，也就使得大泥球越發的複雜和雜亂無章。最終會使得這個系統的代碼不被程式員了解，更無法對其修複，無法滿足使用者的需求變化。
3. 産生的原因：
首先，程式員在編寫程式或是系統時遇到問題後的解決方法，往往不是合适的或者最優的解法，而是友善修改的，變動最小的，這就為以後的系統架構的混亂甚至整個系統的奔潰埋下了隐患。其次，使用者的需求或者程式設計的要求是在不斷地變化的，任何一個已有的系統都随之會産生重大的變化，使得系統越來越複雜化，維護也越來越昂貴，另外編寫人員的變動等等因素都會導緻系統的退化，一步步變為大泥球。
是以，可以将其産生的原因歸結為：一次性代碼，碎片式增長，缺少前期設計，應對需求和架構變化過晚，程式員的經驗，技巧，眼界的限制。
4.避免或者修改大泥球的方法：
首先，程式員或者設計師為了在預算中并按時傳遞高品質的軟體，就需要關注軟體的特性和功能，然後集中在架構和性能，使得軟體設計初步就避免産生小的問題或者方向的偏差。其次，程式員在編寫軟體時要及時的解決出現的小問題或者原型概念等等，這樣不會使得問題堆積導緻後期的無法修改。另外，應當及時處理使用者需求的變化，由于需求往往會随着時間的推移而變化，是以應當逐漸的解決，并且鼓勵和積極面對變化而不是掩蓋問題。另外，要保持一直工作的狀态，不斷地維護需求和系統。但不應當進行一次徹底的檢查，這樣很可能會破壞系統。當然，軟體系統也是在變化的，但是不同的部分會以不同的速度變化，是以應當使得它們的變化率一緻。最壞的結果就是代碼已經下降到了無法修複甚至了解的地步，那麼就扔掉，重新開始。
其實簡單的說就是缺乏設計就開始程式設計所造成的泥沼，越是想改卻越陷越深。
瀑布模型（Waterfall Model） 是一個項目開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到産品釋出和維護，每個階段都會産生循環回報，是以，如果有資訊未被覆寫或者發現了問題，那麼最好 “傳回”上一個階段并進行适當的修改，項目開發程序從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。包括軟體工程開發、企業項目開發、産品生産以及市場銷售等構造瀑布模型。
我們團隊主要是PM分工比較明确，而且所配置設定的任務也都符合每個人能勝任的範圍，主要實作由兩位同學實作，一個人負責伺服器端，一個人負責前端（另一人負責寫部分前端邏輯），而另外幾名同學合作完成計算核心。