３周遅れくらいのところからTDDとかリファクタリングとかを見てみる

従来型（？ というか、私の会社では結構やってる）の、それなりに品質を高くしようとしているプロジェクトでよくある光景では、

後輩：「hoge機能の実装できました！検証してください！」（キラキラした目で）
（仕様書とソースをプリントアウトした紙とテスト仕様書とテストデータ、テスト結果のダンプ、さらにはコーディング規約に合致していることを示すチェックシートを積み重ねた紙束に、「検証依頼書」なるドキュメントを乗っけて抱えている）
先輩：「お、できたか。よしよし。」
（一時間後）
先輩：「hugoクン、ちょっと来て」
後輩：「！」（ビクッ）
先輩：「ここなんだけど… 処理が重複してるよね。」
後輩：「……」（硬直）
先輩：「あと、このメソッドすごく長いんだけど、こういう風に分けたらどうかな。」
後輩：「…………」（リーダーに「また手戻りか。きちんと仕事しろ」と怒られるシーンの想像で頭がいっぱい。もう聞いてない）
先輩：「それから、ここは引数の数が多いから、オブジェクトにまとめる方がいいよね。」
後輩：「………………」（涙目）
先輩：（後輩の様子を見て）「……でもまあ、バグはなさそうだよ。規約違反もないし。次から気をつけてね」
後輩：「はいっ！」（すばらしい笑顔で）

かくして、先輩の目から見れば「汚い」コードが生き残っていくわけです。
TDDでコードを改善するコストを下げ、リファクタリング（のパターン）でコードを改善する方法を伝える効率が上がれば、もっと技術者としての良心に従ったプログラミングをする（誇りを取り戻す！）ことができるように思います。