Мой опыт говорит мне TDD. Свой личный проект я буду писать так.
Кто-то когда-то говорил, что есть как минимум один тип проектов, которым пофиг, что ты там делаешь - они тебя проглотят и выплюнут. Когда приходится фиксить за кем-то баги, в приложении, который уже прошел 1000 человек и имеет версию 12ю, написанный на непонятно каких технологиях и не подкрепленный вообще ни одним тестом. В нем ни юнит теста написать толком не получится, а сотка функциональных будет работать два часа. Ладно, если бы тебя оставили в каком-то одном модуле работать, верю со временем каждый уважающий себя программист навел бы там минимальный порядок, но нет же. Проект состоит из 50 000 джава классов, и тебя бросают из одного класса в другой (баги все же). Вся задача сводится к дебагу, внесению еще одного if :) и отправки кода в реппозиторий. Мало того, бывает так, что ты начал фиксить багу, а тебя вдруг забирают с текущего таска и говорят - кинь каку, важно сейчас другое! И ты уже изучаешь новое хитросплетение зависимостей. Ах да! Забыл! Каждое утро при апдейте валится и билд и все твои тесты... Пол дня делаешь апдейт, пол дня чинишь билд, пол дня тесты :) В таких исключительных случаях TDD практика превращается в испытание.
Зачем тесты? Снизить стресс от страха что-то поломать. Но если все работает так, что ожидается, что ты внесешь новую багу с фиксом старой - тогда и стресса быть не должно. В таких проектах ни рефакторинга ни архитектуры ни code conventions - ничего не надо. Чем примечательны такие проекты так это тем, что на них можно оттачивать свое agile мастерство.
А DDT, кстати, это еще и дихлордифинилтрихлорметилметан, инсектицид.