传统的文件管理软件原理　

　　在想快之前先保证正确：要使一个可用的程序运行得更快些，远比让一个运行得快的程序可用容易得多。在开始阶段的编码中不要考虑优化的问题。这是一个富有洞察力的原则。有些软件专家或多或少地做出过这样的错误陈述：“文件管理软件系统前期的性能问题肯定是下游风险的征兆。”而据我所知，每个成功的、重大的软件项目都在生命周期的前期出现过性能问题。几乎所有的不成熟构架（特别是大型系统）在它们的第一次迭代中都有性能问题。让程序早点开始执行可用是理解复杂性能折衷的一个前提要求。
　　评审代码：评审详细设计和代码来查错，是一个比测试好得多的方法。人们过分夸大了这种方法的价值，当然除了最简单的软件系统外。今天的硬件资源、编程语言和自动化环境使得在生命周期的全过程可以进行自动化的分析和测试。任何一个现代迭代式开发必然需要进行持续的、自动化的生命周期测试。通常来说，毫无方向的评审（与集中在已告知问题的评审相反）极少能够发现构架上的和全局的设计问题。这并不是说所有的评审都效率不高。当正确的使用并集中在一个已知的问题上时，评审对于解决问题是非常有效的。然而这个原则不应放在最好的15个原则当中，尤其是考虑到产业界默认的实践中都过多的使用了评审的情况。
　　好的管理比好的技术更重要：最好的技术并不能补偿差的管理，而一个好的经理可以用贫乏的资源取得伟大的成果。好的管理推动人们发挥自己最好的一面，但没有一种普遍“正确”的管理风格。一个伟大的、管理良好的群组可以在预算和进度都很紧张的情况下做出伟大的东西。而在另一方面，好的管理和群组在质量上的欠缺是互斥的两个方面，因为一个好的经理可以吸引、配置和保持一个高质量的群组。