书中说软件开发过程中遇到的最多的问题是“项目的进度远远落后于计划”。Chandler计划是3~4个月发布一个版本，但是每个版本都花了6个月以上的时间，这里面有诸多的原因。首先合适的衡量开发进度本身就是一件非常难的事情，也就是说计划本身太苛刻了。即使是检测软件开发的进度也是一件很痛苦的事情，用代码数量或者缺陷减少数目来衡量有过偏颇，文中提到了MBWA的方法，但是这个方法很难得到一个总体的开发进度。其次是软件开发的计划往往超出了能预见的范围，致使软件开发一只停留在设计阶段，引用文中的一句话,“用今天的工具和过程，加上昨天的内存限制，我们真的能做的更好”。另外就是软件的缺陷，Chandler在开发过程似乎中似乎掉进了缺陷的泥潭中，他们花了大量的时间用于修复软件的缺陷，如何减少软件开发过程的缺陷也是个头大的事情。
在搞掂设计方案这一章中，我看到了书中提到的边缘案例，这就如同我们目前所做的结对开发中的数组中的子数组最大值超过了int32的表示范围时，我们该怎么办。程序员们经过训练要巨细靡遗通盘考虑，他们太执着于警惕会出问题的情形，结果难免会迟钝不灵。他们在边缘案例上绞尽脑汁，以至于偏离了中心店。而我也感同身受，我们目前的学习，和做软件还是有很大区别的。我们先考虑的都是怎么实现老师要求的这些功能，并没有把用户想像成一些根本不懂程序的人来看待，我们所做的程序，唯一用户就是任课老师。
我们总是希望自己的项目能做到最好，但实际上，只要各个部分比较好就足以让整个项目最好了。要让局部也最优的话，项目不可能完成。当然，书中另一个比较有意思的细节是对软件工程方法的打分表，总共12项，而书中明确提到微软满分。该书风趣地比喻这就像是军队中整理内务一样虽然繁琐但是却保证程序员随时在最佳状态，进入这种状态充分说明微软帝国目前的庞大以及维系这种庞大需要多么繁琐的工序。