Очевидно, что прототипирование приложений использует другой набор технологий, чем разработка производственного класса. Несмотря на то, что они пересекаются — и на самом деле один и тот же фреймворк может использоваться для обоих — часто предпочтительнее писать быстрый и грязный код одним способом, а «постоянный» производственный код — другим. На самом деле, при быстром повторении имеет смысл написать компонент с ожиданием, что он будет выброшен. Напишите его, чтобы потом переписать с нуля — и это все равно быстрее и качественнее, чем писать его «хорошо» в первый раз.

Пример: разработка на основе тестирования (TDD) может быть ненужной и вредной во время быстрого развития. Есть и обратная сторона аргумента: если вы застряли... напишите несколько тестов. Или, если код стал полностью неуправляемым, отключите его, написав тесты. Менталитет тестировщика хорош, и он помогает избавиться от застревания, и он определенно помогает писать долгосрочный поддерживающий код. Однако, если вы знаете, что код может быть выброшен или переписан, или даже переписан более одного раза, то тест-драйв может быть неэффективным и должен быть оставлен.