Wikipedia’ya göre;
Techinal Debt, - aynı zamanda design debt veya code debt olarak da bilinir - daha uzun sürecek daha iyi bir yaklaşım kullanmak yerine, sorunu hemen çözmek için daha kolay bir çözüm seçmek ve bunun neden olduğu yeniden çalışmanın (rework) maliyetini yansıtan bir kavramdır.
Örneğin, Scrum kullanarak bir yazılım geliştiriyorsunuz ve bir sprint sonunda müşteriye yazılımınızın yeni bir versiyonunu sunacaksınız. Tam bu sırada bir hata farkettiniz ve diyelim ki yazdığınız bir fonksiyondaki bir döngü, sonsuz döngüye girdi çünkü aldığı parametrelerde hata vardı ve o hata da başka bir fonsiyondan kaynaklanıyordu. Siz de bunu acilen çözmek için ve döngüden çıkması için hard-coded olarak bir koşul koydunuz ve çalıştı. Müşteriye yazılım son dakikada çalışır olarak gösterildi. Ancak, hatalı kısmı, sonrasında daha doğru hale getirmediniz ve o koyduğunuz koşul da orada kaldı. Başka bir örnek ise kodun hatalı kısmının son dakikada doğru çalışması için veritabanına elle müdahale ettiniz.
Bu gibi işlemler kod içinde, tasarımda, veritabanında ve ilgili heryerde arttığında, yazılımın bakımı zorlaşacak ve dolasıyla da kalitesi düşecektir. Technical Debt, yazılım kalitesi ve bakımı ile ters orantılıdır.
Technical Debt, istenmeyen ama yukarıdaki örnekteki gibi durumlarda kaçınılması zor olan bir kavramdır. Önemli olan bunu yönetilebilir bir düzeyde tutmaktır. Bu tarz acele ve kısa çözümler yazılımda arttıkça ve sonrasında düzeltilmedikçe, yazılım, dokunulması ve iyileştirilebilmesi kabus hatta imkansız hale gelen ve yeter ki çalışsın denilen, ufak tefek yamalarla günü kurtaran bir yazılım hale gelecek, tek bir kişide ve bir takımda tekelleşecek ve en sonunda da yeniden yazılması mecbur hale gelecektir.
Peki ne yapılabilir?
1-Technical Debt’e sebep olan koşullar ve sebep olan işlemler şeffaf olmalı, herkes farkında olmalıdır. Hatta her sprint sonunda müşteriye ile beraber de bunları ele alabilirsiniz.
2-Techinal Debt’i gösteren kod metrikleri alabilirsiniz. Örneğin, cyclomatic complexity, code coverage ya da en azından bug ları sayabilirsiniz. Bunları yapan pek çok araç bulunmaktadır.
3-Her sprint zamanının bir kısımını, technical debt’i düşürmek için yani daha önce yapılmış kısa çözümler yerine daha doğrularını yazmak için ayırabilirsiniz.
4- Yazılımın bitti'sini (definition of done) belirleyen kriterlerden biri de kodlama standartları ve tasarım standartları olabilir. Böylece, zaten kod ve tasarım gözden geçirileceği için, standartlara uymayan kodlar ve tasarımlar iyileştirilecektir.
