小化未完成的编码任务的工作包（backlog）。当开发人员开发一个设计用例时，有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。 把未修改完成的代码保存到本地数天或数星期，这样增加了工作浪费的风险，会出现返工。 想象有三个任务，每个估计都要。 如果三个一起开发，并行起来每个都需要3天，这样一累计会有9个’单位’的风险。 如果顺序的开发，一个开发完成后再开发另一个，只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们，当我们在这种情况下时，我们希望三个一起完成。 但是软件不像盖房子。 小的、迅速的、完整的任务不仅仅会降低我们的认知负荷，也减少了进行中的开发对其他人正在进行的开发的相互影响。
　　不要过度功能范化。也是我们所说的 “YAGNI – You Aren’t Going to Need It” 。 程序员在编写一个类时喜欢料想：这个类可能在其它地方其它类中会有其它用途用． 如果这些用途是被当前的用例用到，那这样思考是没错的，但常常开发人员想到的这些用途都是目前不存在的用途，实际上可能是永远不会用到的用途。 (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax， and a dessert topping.)
　　如果两行代码能完成不要写成三行。简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。 精简的、书写规范的代码易于维护和查找错误，冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。
　　永远不要按行数多少来评价代码头。编写某个任务所产生的代码行数会因程序员而异，因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。 代码质量可以相差200倍之多，这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。
　　我们应不断的再设计、再分析。 应用这一条时你要非常的小心，因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的，但现在有个用例需要它是浮点型，不要害怕去改变它，只要你按步骤：测试，写文档，布署。
　　删除死代码。当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说，我们需要往类里添加一个新方法来替换以前的旧方法，通用人们会保留老方法‘以防不测’。 其实，我们应该花一些功夫去检查看看这个老方法是否还有用，如果没有证据显示它还有用，该删掉它。 更糟糕的错误做法是把这些代码注释掉，留下一堆注释码。 注释掉的代码一旦发现该被删掉，不能留到测试时还有、甚至提交到代码库。 添加代码总是容易的，删除代码总是困难的。 因此，一旦发现有可能没用的代码，你应该花点时去确认它、删除它，这样会让代码更加可维护。
　　不要自创新语言。程序员喜欢使用文本文件来实现功能性的趋动，这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现，人们试图通过文件的配置以让终用户‘编程’来控制软件的功能、避免重新编译。 这种设计上的缺陷是：软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。 所以，真正的终用户是不可能知道软件的内部工作机理的，不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途，也不应该被抵制，但设计人员必须以非常非常安全的方式使用它们，尽可能使用现有的语言，必免使用新发明的语言。
　　只有当准备好了实现和测试才去确定设计。我应该有一个总体的认识我们要做什么，应该有个总体架构目标，而不是详细设计、详细的具体方法的实现，只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。 详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中大的浪费是你花时间设计出来东西后被告知不需要了，或者是你的设计一开始建立在错误的假设上。
　　软件是可塑的。软件不像盖房子，我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。 而且，软件产品和设计之间的互动明显比规格说明书有效率。 所以，你应该直接实现你的设计，这样客户能很容易明白你的设计细节。 当发现有问题、要改变设计时，修改软件要比修改文档容易的多。 更重要的是，当客户看到了能运行的程序后，你也更能搞清客户的需求是什么了。
　　对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。程序员一般都非常的懒，抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误，他会记得这种一直使用的错误描述信息是什么意思。 但站在客服技术支持的处境，他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。
　　上面这些条目没有特别的顺序。 欢迎对这些我汇总的指导原则进行评论，也许你并不认可其中的几条，也请发表你们意见。