Claramente, el prototipado de aplicaciones utiliza un conjunto diferente de tecnologías que el desarrollo de grado de producción. Aunque se solapan - y de hecho el mismo marco puede ser utilizado para ambos - es a menudo preferible escribir código rápido y sucio de una manera, y código de producción "permanente" en otra. De hecho, cuando se iteran rápidamente, tiene sentido escribir un componente con la expectativa de que será arrojado. Escríbalo para reescribirlo desde cero más tarde - y eso es aún más rápido y más alta calidad que escribirlo "bien" la primera vez.

Case in point: test-driven development (TDD) may be unnecessary and detrimental during quick development. También hay el lado contrario del argumento: si te atascas... escribe algunas pruebas. O si el código se convirtió en completamente inmanejable, desengancharlo escribiendo pruebas. La mentalidad de los testers es buena, y ayuda a conseguir un no-estuck, y definitivamente ayuda a escribir código de mantenimiento a largo plazo. Sin embargo, si usted sabe que el código puede ser expulsado o reescrito, o incluso reescrito más de una vez - que el test-driven puede ser ineficaz y debe ser abandonado.