重构和重写的目标，都是要通过提高的代码的可读性、结构和清晰性，从而提高系统的健壮性。清晰的代码更易于维护和改善。然而，在很多情况下，敏捷团队会难以在二者之间做出选择。
代码会随着时间的流逝变得越来越差，Michael Dubakov为此指出了下面的原因：
Michael 建议，虽然重构和重写都会使代码更加清晰，但是这两种技术都会导致现有系统的混乱。重构是一种增量式的活动，因此它每次只会接触到系统的一部分。这会在局部造成混乱，可能还比较容易控制。而另一方面，重写是更具有攻击性的改变，它会导致系统中更大的混乱。由于它会造成更广泛的影响，因此要想让重写的影响稳定下来，时间要比重构长得多。
Peter Schuh认为团队经常会将两个词彼此替换使用，从而导致更多的迷惑和混乱。团队应该知道：和重构相比，重写更具有风险，因此应该恰当地使用术语。据他所说：
Guido A.J. Stevens的想法很有趣，他认为问题并非出在重构和重写之间，而是在于： 或者重构，或者重写并重构 。他提出：即使当团队决定重写系统的时候，最终他们也会有两个系统并行运行。旧系统需要重构，而新系统正在被重写。这种组合变成了一项极度复杂的任务，据他所说：
Naresh Jain对于遗留代码有下面特别的的建议。当代码难于理解，并且团队不能确定它做什么的时候进行重构。当很清楚知道代码做什么，但是很难理解那些代码的时候就重写。
因此，重构是不断提升系统更好的方式。它是慢速前进的，通过小的、经常的提升来提高质量。重写也有其自身的优势，然而在很多情况下它是一种有风险的选择，并且团队可能永远都不确定产出物的情况。正如“Joel 说软件”中所说：
查看英文原文： Refactor or Rewrite?
