所有软件创作都包括了本质性工作（essential task）和附属性工作（accidental task）。前者是去创造出一种由抽象的软件实体所组成的复杂概念结构，后者则是用编程语言来表现这些抽象的实体，并在某些空间和速度的限制之下，将程序对应至机器语言。
现在，若跟本质性的工作相比，软件工程人员所做的事，还有多少算是花在附属性的工作上呢？除非附属性工作要耗费的心力超过全部工作的9/10，否则就算是将所有的附属性工作降至零，也无法将整个开发工作的轻松程度提升一个数量级。
以往，软件生产力的重要进展绝大部分是来自于人为障碍的排除，像是严苛的硬件限制、难用的编程语言、上机时间（machine time）的不足等等，这些都是造成附属性工作益发困难的原因。
- 复杂性（complexity）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
- 隐匿性（invisibility）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
- 配合性（conformity）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
- 易变性（changeability）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。
大泥球（Big Ball of Mud）
1. 定义：
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。
2. 缺点：
无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
3. 产生的原因：
首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会导致系统的退化，一步步变为大泥球。
所以，可以将其产生的原因归结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
4.避免或者修改大泥球的方法：
首先，程序员或者设计师为了在预算中并按时交付高质量的软件，就需要关注软件的特性和功能，然后集中在架构和性能，使得软件设计初步就避免产生小的问题或者方向的偏差。其次，程序员在编写软件时要及时的解决出现的小问题或者原型概念等等，这样不会使得问题堆积导致后期的无法修改。另外，应当及时处理用户需求的变化，由于需求往往会随着时间的推移而变化，所以应当逐步的解决，并且鼓励和积极面对变化而不是掩盖问题。另外，要保持一直工作的状态，不断地维护需求和系统。但不应当进行一次彻底的检查，这样很可能会破坏系统。当然，软件系统也是在变化的，但是不同的部分会以不同的速度变化，所以应当使得它们的变化率一致。最坏的结果就是代码已经下降到了无法修复甚至理解的地步，那么就扔掉，重新开始。
其实简单的说就是缺乏设计就开始编程所造成的泥沼，越是想改却越陷越深。
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
我们团队主要是PM分工比较明确，而且所分配的任务也都符合每个人能胜任的范围，主要实现由两位同学实现，一个人负责服务器端，一个人负责前端（另一人负责写部分前端逻辑），而另外几名同学合作完成计算核心。