Yazılım geliştirme süreçlerinde "refactoring" veya kod iyileştirme, sıkça tartışılan bir konudur. Makale, refactoring'in ayrı bir "story" olarak product backlog'a eklenmesinin neden hatalı bir yaklaşım olduğunu açıklıyor. Projenin başlangıcında kod tabanı temiz ve yönetilebilirdir. Ancak yeni özellikler eklenirken, aceleci davranma ve küçük "kısa yollar" alma eğilimi, kod kalitesinde düşüşe yol açar. Bu durum, "technical debt" olarak adlandırılsa da, aslında sadece iyi yazılmamış koddur. Başlangıçta fark edilmeyen bu küçük aksaklıklar, zamanla birikerek kod tabanını "otlarla kaplı bir tarlaya" dönüştürür.
Kod kalitesi düştükçe, yeni özellikler geliştirmek daha zor ve yavaş hale gelir. Geliştiriciler, mevcut karmaşanın etrafından dolanmak veya zorla içinden geçmek zorunda kalır, bu da hızı daha da düşürür. Sorunlar belirginleştiğinde, büyük bir refactoring seansı talep etme isteği doğar. Ancak bu tür büyük çaplı iyileştirmeler, product owner'a satılması zor bir fikirdir çünkü geçmişteki hataları düzeltmek için zaman istenmektedir. Eğer bu zaman ayrılsa bile, genellikle yetersiz kalır ve beklenen verimi sağlamaz; çünkü kodun bu hale gelmesi haftalar sürmüşken, düzeltmek için aynı süre verilmez.
Makale, bu yaklaşımın yanlış olduğunu vurgular ve alternatif bir çözüm sunar: Refactoring, ayrı bir görev olarak değil, yeni özellik geliştirme sürecinin doğal bir parçası olmalıdır. Yeni bir özellik üzerinde çalışırken, ilgili kod alanındaki "otları temizleyerek" bir yol açılmalıdır. Yani, sadece üzerinde çalışılan kısımlar iyileştirilmeli, diğer kısımlar ise şimdilik göz ardı edilmelidir. Bu, sürekli ve küçük adımlarla kod kalitesini artırarak, büyük ve sancılı refactoring projelerine olan ihtiyacı ortadan kaldırır ve geliştirme hızının sürdürülebilir olmasına yardımcı olur.
Sürekli ve küçük adımlarla yapılan refactoring'in, büyük ve planlı iyileştirme projelerinden daha etkili ve sürdürülebilir bir yazılım geliştirme pratiği olduğu vurgulanmaktadır.