Teknik Borç Nedir?

Bu makalede Teknik Borç Nedir, Teknik Borcun Türleri, Teknik Borcun Maliyeti ve Teknik Borcun Sonuçlarına değinmeye çalışacağım. Hikayemiz şöyle başlıyor. Üç arkadaş öğle yemeğinde konuşuyorlar:

– Sabah yazılım geliştirme ekibiyle toplantımız vardı. Bireysel kredi başvuru raporlarına iki yeni alan eklemelerini istedik. Bu iki alanı ne kadar zamanda teslim edecekler, biliyor musun?

– İki alan olduğuna göre arkadaşlarında keyifleri yerindeyse iki günde bitirirler herhalde.

– Ahahaha. Gerçekten yazılımcı olmak varmış. Adamlar yata yata para kazanıyorlar! Bütün gün bilgisayar başında otur ve hiçbir şey yapmadan dünyanın parasını kazan. İki alan için dört hafta süre verdiler desem ne dersin?

– Bu işe girmeliydik derim…

İster inanın ister inanmayın bu konuşmalar gerçekleşiyor. Bazen yazılım geliştirenlerin yüzüne karşı gülümseyerek söyleniyor bu sözler, bazen toplantılarda sert tartışmaların içinde geçiyor. “İki alan eklemenizi istedik dört hafta süre veriyorsunuz!” Daha sonra Genel Müdür Yardımcısı ve Müdürlerin eklendiği e-postalar atılır. Gerginlik dolu anlar yaşanır. Talebin alınmasının üstünden bir hafta geçer iş biriminde çalışan kişi yöneticisine hatırlatır. Yönetici, ürünü geliştiren ekibin yöneticisine azarlayan bir e-posta gönderir. Ürünü geliştiren ekibin yöneticisi ekibine azarlayan bir e-posta gönderir ve işin ne zaman biteceğini sorar. İş üç hafta içinde bitecektir. Bu gerginlik dört hafta boyunca böyle devam eder ve dördüncü haftaya gelindiğinde eğer iş birimi şanslıysa gerekli iki alan rapora eklenmiştir.

İki alanın dört haftada eklenmesinin nedeni yazılım ekibinin geçmişte aldığı teknik borçları ödememesidir. Ekibin yıllarca biriken borçları ödemesini bırakın borcun faizini bile ödemeye gücü yetmeyebilir. İki alanı eklemek gerçekten iki gün sürebilir. Yazılım ekibinin diğer onsekiz gün boyunca yaptığı iş: borç + faiz’in ödenmesidir.

Teknik Borç Benzetmesi

İlk defa Ward Cunningham tarafından kullanılmıştır. Cunningham Wiki’nin kurucusudur. Extreme Programming ve Design Pattern’in öncülerindendir.(1)

Teknik Borç tıpkı finansal borç gibi alındığında faiziyle birlikte geri ödenmesi gereken borçtur. Bir işlevselliğin ürüne eklenmesi istendiğinde iki yol izlenebilir.

Birincisi hızlı fakat daha sonra üründe yapılmak istenen değişikliklerde yolu tıkayabilecek ve uğraştırabilecek olandır.

İkinci yol ise daha uzun sürecek fakat ürünün esnekliğini koruyacak ve gelecekte yapılacak değişikliklerin önünü kapatmayacak olandır.

Teknik Borç Türleri

Kaçınılmaz Teknik Borç: Öngörülemeyen ve önlenemeyen teknik borçtur ve ürünü geliştiren takımın burada herhangi bir hatası yoktur.

Stratejik Teknik Borç: Pazara çıkma süresiyle ilgili karar neticesinde alınan teknik borçtur. Burada alınacak karar sadece ürünü geliştiren ekip tarafından verilmemelidir. Bu karar alınırken iş birimlerine veya müşterilere bilgi verilmeli ve görüşleri alınmalıdır. Sonuçta pazara rakiplerden önce çıkmanın avantajlarını ilgili iş birimleri veya müşteriler daha iyi bilirler. Pazara erken çıkıp pazar avantajı elde etmek istiyorlarsa geliştirme ekibinin nasıl bir teknik borç aldığını ve ileride ödemesi gerektiğini herkes bilmeli ve karar böyle verilmelidir. İş birimlerinin ya da ürünü kullanan müşterilerinizden teknik borç aldığınızı saklamak kötü bir pratiktir. Sizi yukarıdaki diyalogta olduğu gibi yargılamalarına neden olabilir.

Taktiksel Teknik Borç: Stratejik Teknik Borç’tan farklı olarak ürünü geliştiren ekip tarafından alınan karar neticesinde ortaya çıkar. Genellikle projenin bitiş tarihinden kaynaklanır. Kısa zamanda işlerin yetiştirilmesi ve yakın bir tarihte gerekli düzenlemelerin yapılacağı göz önünde bulundurularak ortaya çıkar.

Naif Teknik Borç: Yeterli yetkinlik sahibi olmayan ya da yeterli yetkinlik sahibi olup gerekli özeni göstermeyen kişiler tarafından gerçekleştirilen teknik borçtur. Özetle işe yeni başlayan kişiler ya da işine gerekli ilgiyi göstermeyen kişiler tarafından gerçekleştirilir.

Artımlı Teknik Borç: Geçmişte oluşturulan teknik borçların ödenmeden var olan teknik borcun üstüne yeni teknik borçların eklenmesidir. İşi bir an önce bitirmek için gerçekleştirilen yüzlerce, binlerce küçük kısa yolun oluşturulmasıyla ortaya çıkar.

Teknik Borcu Olmayan Ürün Yoktur

Çok iyi kod yazabilirsiniz, ürünün yapısı üstünde çok çalışıp gerçekten çok iyi bir tasarım ortaya çıkartabilirsiniz, gelecekte eklenmesi istenen özellikleri eklemede herhangi bir teknik engelle karşılaşmayacak bir yapı kurabilirsiniz, bu teknik borcunuzun olmadığı anlamına gelmez. Yapılan her tasarımla ve yazılan her satır kodla teknik borç oluşturulur. İsterseniz kısa zamanda tasarlanan ve kirli bir kodla yazılan yolu seçin isterseniz uzun sürede itinayla tasarlanmış ve temiz kodla yazılmış yolu seçin teknik borcun ve teknik borcun faizinin oluşmasının önüne geçemezsiniz.

1. Yol: Kötü tasarım + kirli kod = 5x kadar teknik borç + %90 faiz
2. Yol: İyi tasarım + temiz kod = x kadar teknik borç + %10 faiz

*Buradaki formülü akıllarda birşeyler oluşması için veriyorum. İyi tasarım ve kötü tasarımla, temiz kod ve kirli kod arasındaki teknik borç farkını daha kolay anlatabilmek için bir benzetme.

Birinci ve ikinci yol arasında seçim yapma şansınız varsa burada stratejik düşünmelisiniz. Ürünü hızlı bir şekilde geliştirip pazara ilk çıkan ürün olarak sunabilir ve pazar payının çoğunluğuna sahip olabilirsiniz. Böyle bir ortamda Teknik Borç almak gayet mantıklı olabilir. Sonuçta Teknik Borcun maliyetini karşılayacak parayı ve fazlasını kazanacak olabilirsiniz.

Pazardan istediğiniz faydayı sağladıktan sonra ürününüzün ömrü uzun olacaksa teknik borcunuzu ödeyebilirsiniz. Ürün teknik borcuyla yaşıyorsa ve yeni bir işlevsellik eklenmeyecekse ürün teknik borcuyla yaşamaya da devam edebilir. Bütün teknik borçlar ödenmek zorunda değildir.

Ürünü geliştirmek için zamanınız varsa ürünün hayatı uzun olacaksa örneğin kurumsal bir firmada 8-10 yıl kullanılacak ve zaman içinde yeni özellikler eklenecekse teknik borç yaratmamanız daha doğru olur. Çünkü yarattığınız teknik borç kurumsal yapının karmaşıklığı içinde sürekli olarak karşınıza çıkacaktır.

Teknik Borcun Maliyeti

Teknik Borcun maliyeti sadece geliştirme ekipleri tarafından ödenmez tüm organizasyon tarafından ödenir. Teknik Borç, paranın, zamanın ve emeğin gerektiğinden fazla harcanmasına neden olur. Küçük takımlardan büyük organizasyonlara, yazılım geliştiren ekipler bütçelerinin %80’inden fazlasını kodun bakımına harcarlar.(2) Bunu bir ülkedeki yazılım geliştiren tüm ekiplerin yapması gerektiğini düşünürseniz aslında Teknik Borcun ülke ekonomisi boyutunda bir etkisi olduğunu görebilirsiniz.

Teknik Borcun ne kadar maliyeti olduğu bilinmez.(3) Teknik Borcun hesaplanabilmesi için herhangi bir ekonomi modeli yoktur. Bunu hesaplamaya çalışabilirsiniz ya da bu hesabı yapan araçlar kullanabilirsiniz fakat buradan elde edeceğiniz veriler gelecekteki riski hesaplayabilmeniz için doğru sonuçlar vermeyecektir ve bu veriler uydurmadır.

Teknik Borcun Sonuçları

Ödenmeyen Teknik Borç zamanla verimliliğin düşmesine neden olacaktır. Verimliliği düşen yazılım geliştiricilerin motivasyonları düşecek ve moralleri bozulacaktır. İşe geldiğinde morali bozulan, motivasyonu düşen yazılım geliştirici mutlu olabileceği başka çalışma yerleri arayacaktır.

Teknik Borcun yüksek olduğu ürünlerde yapılan bir değişiklik bambaşka yerlerde birşeylerin bozulmasına neden olabilir. Bu nedenle ürünün tamamının yeniden test edilmesi gerekecektir. Eğer bu testleri birde elle yapıyorsanız! Teknik Borca ek olarak birde test maliyetleri çıkacak demektir.

Ürüne yeni eklenecek özelliklerin, işlevselliklerin teslim edileceği sürelerin belirlenmesinde yapılan tahminlerde büyük farklılıkların oluşmasına neden olur. Bu nedenle müşterinin istediği işlevselliğin ulaştırılmasında, pazara çıkış zamanınızda sürekli olarak değişimler yaşanacaktır.

Teknik Borç, kopyala/yapıştır kodun oluşmasına neden olur. İstenen özellik mimari anlamda bir değişikliğin yapılmasını gerektirebilir. Böyle bir değişiklik daha çok zaman, para ve efor demektir. Daha fazla zaman, para ve efor harcamayı kimse -proje sponsorları, yazılım geliştirici- istemez. Bu nedenle kopyala/yapıştır kodlar artar.

Doğal süreçte bir yazılım üzerinde çalışıldıkça hata sayısının azalması gerekir. Teknik Borcu yüksek olan bir üründe yaptığınız değişikliğin nereyi etkilediğini bilmek olanaksız olduğu için zamanla hata sayısı artar. Hata sayısındaki bu artış gerçekleştirilen ürünün kalitesizliğini gösterir. Yazının başında söylediğim gibi;

kötü tasarım + kirli kod = kalitesiz ürün

Herhangi bir değişiklik yapmaya korkulur. Çünkü yapılan her değişiklikte bilinmeyen bir yerde başka bir hata oluşturulabilir.
Kodun okunması zorlaşır. Uncle Bob, Clean Code: A Handbook of Agile Software Craftsmanship adlı kitabında yazılım geliştiricilerin bir birim yeni kod yazabilmeleri için yazılmış olan on birimden fazla kodu okumaları gerektiğini söyler. (4) Okunması zor olan kod yeni kodun yazılmasını zorlaştırır.