书中有一段说的是一个闪烁缺陷——在改变某软件中某个窗体的尺寸时，屏幕会闪烁一秒钟左右。虽然该缺陷不会影响程序运行，但它不符合作者的审美观，历时六个多月仍然没能修正。其实在日常的编程中也有许多小bug的棘手程度超乎自己的想象。首先你需要一点一点的去测试，找出问题的根源之所在，然后才是如何最小程度的修改程序，最好不要牵扯程序的其他部分。而我在之前的编程学习中就遇到过类似的问题，本来想去改一个小小的bug，结果这个缺陷修好了，却引起了其他更多的bug，正好符合一句话——“牵一发而动全身”，就令我十分头疼，印象深刻。
书中说过这么一个概念，我看得不是太懂，是关于软件时间的讨论。对软件时间所导致的问题的最早的也是最好的诊断，是来自弗里德里克·布鲁克斯于1975年撰写的《人月神话》一书。布鲁克斯所在的部门，深受进度落后之困，不断招募新程序员参加项目，结果却发现后援力量非但不能援救项目，而且会让状况变得更糟糕。布鲁克斯法则就是这样产生了，使人听起来即是原则也是悖论：向已延误的项目中补充人力，只会使其继续延误。因为他观察到“只有在任务能分派给许多互相之间无需沟通的工作者时，人和月才是可互换品”。对于软件开发而言，项目各有差异、工具不断升级，每当团队中加入一个新成员，老组员就得放下手里的工作，帮助新组员进入角色，每位组员都要等待重新分配任务。然而在你意识到这一切之前，已经远远落后于进度了。虽然我现在只是个体编程，还没有经历过一个团队共同编写一个程序，所以理解不是很深入，有一些东西并不能很好的体会。但是从字面意思有一定的道理，软件开发和零件加工无法类比，当零件加工延误时，可以增加人力，因为每一个人都是都是相互独立的，没有联系；而软件开发就不一样了，需要的是人与人的密切合作，才有可能实现最终的功能。