② 蹩脚的设计过程
从中小项目的特点来看，开发人员少，意味着不同人员的程序之间交互、接口相对少一些；开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者虽是小项目的优势，但却都让人容易犯些错误。比如，实施中往往是几个人碰一下意见，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，并没有一份较正式的文档。这种做法为项目实施带来风险：
其一，有的人可能会对讨论出的接口、结构理解有偏差，应该承认并不是所有参加会议的人总是很明白，人是会犯错误的。而往往一个单纯的误解可能造成以后的返工；
其二，由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于系统设计不充分，没有一个负责协调的人员不断监控整个开发过程；
其三，一旦有人中途退出开发队伍，其他人加入，新来的人因无法理解前人做好的工作，索性自己从头再来。同时，没有文档的程序，日后维护和版本升级也比较困难。
③ 直奔系统测试
项目不经过单元测试而直接进入系统测试，造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。比如为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。
有人嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。 殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步一步查找。同时，由于模块间的调用关系，可能查了很久才发现是某个模块的问题。
这种方法如果侥幸成功，效率可能会很高，但概率不超过40%。所以，总体看来，这种方法一方面效率较低，大量的时间用在了将一个错误定位在模块上；另一方面，由于测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。
