写程序不仅要考虑编译器能执行，更应考虑代码是否有良好的可读性。可读性不仅仅是为了方便别人看你的代码，就算是作者本人，在编写新功能的时候，其实也会反复看自己之前的代码。为了让开发速度快，而放弃让代码保持高品质，其实只会反而拖慢开发速度。编写当前功能的时候，这么做当然是会提高开发速度，但从全盘角度去看，当前的低品质代码，会成为将来新功能的绊脚石。所以，提高代码开发速度的办法是提高代码质量，花额外的时间重构美化自己的代码，其实并不“额外”，它是保障代码不会随着新功能不断增加，而慢慢腐坏最有效的方法。
“光把代码写好可不够，必须时时保持代码整洁。我们都见过代码随时间流逝而腐坏。我们应当更积极地阻止腐坏的发生。每次代码签入时，代码都比签出时干净。”
“我们都曾经瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗法则：稍后等于永不。”
所以我们要保证只写入高质量的代码，永不对自己说“回头再整理他们”。xp极限编程强调编码过程有一个环节是“重构”。
我们都知道代码灵活的重要性，都知道糟糕代码会带来的维护恶果，在面对管理层的时间要求时，要求我们牺牲品质保证进度时，我们一定要坚持地说“不”！管理层不了解糟糕代码的隐患，会觉得重构代码是在浪费时间，但我们要坚持立场。就像病人对医生说“医生，你不要去洗手了，直接动手术吧，我没有时间”，医生不可能听病人的意见，不去洗手一样。医生明白不消毒的后果，不可能听病人的意见。同样，我们明白牺牲代码品质的危害，我们要坚守立场。
如果背负时间的压力，我们不应该以“牺牲代码品质”来提高开发速度，牺牲代码品质事实上只会拖累了自己以后的开发速度，我们应该想办法“让自己做得更快”。什么办法？保持代码的高质量。这是做得快的唯一方法。