项目的工程量是巨大的，一旦设计的方案出现了变化，原本的工程可能不再适用，代码的可撤销性应运而生，为了让代码产生可撤销性，程序员们通常会使用灵活的架构、灵活的代码。但是当编码充满不确定性，我们的代码是否能满足客户的需求时，工程的编写就成了难点。
曳光弹给人们带来了灵感，用“射程较广”不那么精确的代码来揣摩复杂客户的真实需求，拽光开发的理念——总有改动需要完成，总有功能需要增加——代码不再是一蹴而就的工程，而是一个不会结束的过程。
曳光弹并非万能的，它不能一击即中，我们要不断调整“弹道”，直到集中目标，满足用户的需求。
原型与完全制作相比能节省许多费用，同样的，一个软件的原型比之成品的软件也能大大的降低代价。我们常常需要制作原型代码来节省直接制造成品失效时的代价。我们通常在制作原型时使用便笺来提高成功率。
以下这些事物都值得制作原型：
架构
已有系统中的新功能
外部数据的结构或内容
第三方工具或组件
性能问题
用户界面设计
