Teknik Borç Nedir? Hızlı Yazılan Yazılımın Görünmeyen Faturası

Teknik borç, bir yazılımı hızlı çıkarmak için bugün alınan kısayolların, yarın faiziyle birlikte ödenen maliyetidir. Kavram bir benzetmeden gelir: nasıl banka kredisi bugün nakit sağlayıp gelecekte faizle geri ödeniyorsa, kod yazarken alınan 'şimdilik böyle olsun' kararları da bugün zaman kazandırır, gelecekte her değişikliği yavaşlatan ve pahalılaştıran bir yük olarak geri döner.

Bu yazıda teknik borcun ne olduğunu, nasıl oluştuğunu, bir şirket yöneticisinin teknik bilgi olmadan bile fark edebileceği belirtilerini, şirkete gerçek maliyetini, her teknik borcun kötü olup olmadığını, nasıl ölçülüp yönetileceğini ve nasıl ödeneceğini anlatacağız. Yazılımınız 'eskiden hızlı geliştirilirdi, şimdi her şey uzun sürüyor' aşamasındaysa büyük olasılıkla bu yazının konusuyla karşı karşıyasınız.

Teknik borç nedir?

Teknik borç, yazılım geliştirilirken hız, bütçe ya da bilgi eksikliği nedeniyle ideal olmayan çözümlerin tercih edilmesi sonucu birikimli olarak oluşan ve her yeni geliştirmeyi daha zor, daha yavaş ve daha riskli hale getiren yapısal yüktür. Kullanıcı ekranda görmez; ekip her değişiklikte hisseder.

Borç benzetmesinin iki parçası vardır: anapara ve faiz. Anapara, kısayolun kendisidir; kopyala yapıştırla çoğaltılmış kod, test yazılmamış modül, elle yönetilen bir ayar, belgelenmemiş bir entegrasyon. Faiz ise bu kısayolun her geliştirmede ödettiği ek zamandır; aynı düzeltmeyi beş yerde yapmak, her değişiklikten sonra elle test etmek, entegrasyonun nasıl çalıştığını her seferinde yeniden çözmek.

Faiz, anapara ödenmediği sürece birikir. Başta önemsiz görünen bir kısayol, üzerine inşa edilen her özellikle daha pahalı hale gelir; iki yıl sonra o kısayolu düzeltmek, başta doğru yapmanın on katına mal olabilir. Bu yüzden teknik borç yalnızca teknik bir kavram değil, finansal bir kavramdır.

Teknik borç nasıl oluşur?

Teknik borç dört ana nedenle oluşur: teslim baskısı altında bilinçli alınan kısayollar, ekibin deneyim eksikliğinden kaynaklanan yanlış tasarım kararları, keşif aşamasının eksik yapılması nedeniyle sonradan değişen gereksinimler ve zamanla eskiyen teknolojilerin güncellenmemesi. Bunların yalnızca ilki isteyerek alınan borçtur; diğerleri fark edilmeden birikir.

Teslim baskısı en anlaşılır nedendir. Fuar tarihine yetişmek, yıl sonu kapanışından önce çıkmak, yatırımcıya göstermek gibi gerçek iş sebepleri, 'şimdi böyle yapalım, sonra düzeltiriz' kararlarını üretir. Sorun karar değil, 'sonra'nın hiç gelmemesidir. Teslim biter, yeni istek gelir, düzeltme listesi hep bir sonraki sprinte kalır.

Eksik keşif de sessiz bir borç kaynağıdır. Gereksinim yanlış anlaşıldığında yazılan kod doğru anlaşılan gereksinime yamalanır; yama üstüne yama gelir ve sistem orijinal tasarımdan uzaklaşır. Bir de teknoloji yaşlanması vardır: güncellenmeyen kütüphaneler, desteği biten sürümler, artık kimsenin bilmediği araçlar. Bu tür borç hiç kimse hata yapmadan da oluşur.

Teknik borcun belirtileri neler?

Teknik borcun yönetici tarafından görülebilen belirtileri şunlardır: küçük değişikliklerin beklenmedik uzun sürmesi, bir yerin düzeltilmesinin başka bir yeri bozması, yeni geliştirici katılımının aylar alması, 'o modüle dokunmayalım' cümlesinin duyulması, her sürümden sonra hata dalgası gelmesi ve tahminlerin sürekli sapması. Kod okumadan bu belirtiler yeterli uyarıdır.

'Küçük bir değişiklik ne kadar sürer' sorusuna verilen cevabın zamanla uzaması, en net göstergedir. Bir alan eklemek ilk yıl bir gün sürüyorsa ve üçüncü yıl bir hafta sürüyorsa, aradaki fark teknik borcun faizidir. Benzer biçimde, ekibin bazı bölümlere dokunmaktan çekinmesi, o bölümlerin artık kimsenin tam anlamadığı bir karmaşıklığa ulaştığını gösterir.

Bir diğer belirti, sistemin tek bir kişiye bağımlı olmasıdır. 'Bunu yalnızca Ahmet bilir' durumu, belgeleme ve düzen eksikliğinin sonucudur ve o kişi ayrıldığında borç bir anda vadesi gelmiş hale gelir. Yeni gelen geliştiricinin verimli olması için gereken süre, borcun dolaylı bir ölçüsüdür.

Teknik borç şirkete ne kadara mal olur?

Teknik borcun şirkete maliyeti, yavaşlayan geliştirme hızı, artan hata ve kesinti sayısı, yükselen bakım bedeli, güvenlik riski ve pazara geç çıkma olarak ortaya çıkar; bu kalemlerin hiçbiri faturada 'teknik borç' diye yazmaz, ancak toplamı geliştirme bütçesinin büyük bir bölümünü sessizce yutabilir. En büyük maliyet, yapılamayan işlerin fırsat maliyetidir.

Somut bir örnekle düşünelim: ekip zamanının yarısını eski sorunlarla uğraşmaya harcıyorsa, yeni özellik üretme kapasitesi yarıya inmiştir. Rakip aynı sürede iki kat özellik çıkarır. Bu fark bir çeyrekte fark edilmez ama iki yılda pazar konumunu belirler. Borç yalnızca geliştirme maliyetini değil, şirketin hareket kabiliyetini de tüketir.

Güvenlik maliyeti ayrı bir başlıktır. Güncellenmeyen kütüphaneler bilinen açıklar taşır; belgelenmemiş sistemlerde kimin neye eriştiği net değildir. KVKK kapsamında kişisel veri işleyen bir sistemde teknik borç, yalnızca teknik değil hukuki bir risk haline gelir.

Her teknik borç kötü müdür?

Hayır, her teknik borç kötü değildir; bilinçli alınan, kayıt altına konan, sınırlı kapsamlı ve geri ödeme planı olan borç, tıpkı iyi bir yatırım kredisi gibi işe yarar. Kötü olan, farkında olmadan alınan, belgelenmeyen ve hiç ödenmeyen borçtur. Ayrım borcun varlığında değil, yönetiminde yatar.

MVP çıkarırken bazı kısayollar almak mantıklıdır. Henüz doğrulanmamış bir özelliği mükemmel yazmak, o özellik gereksiz çıkarsa boşa gider; kaba bir sürümle sahaya çıkıp doğrulandıktan sonra düzgün yazmak daha akıllıcadır. Burada borç, öğrenme hızını satın alan bir araçtır. Şartı, hangi kısayolun nerede alındığının yazılı olması ve doğrulama sonrasında ödenmesidir.

Kötü borç ise genellikle kimsenin bilmediği borçtur. Kod incelemesi yapılmayan, test yazılmayan, belgelenmeyen bir projede borç nerede, ne kadar, kimse bilmez. Böyle bir borç planlanamaz; yalnızca bir gün bir şey kırıldığında ortaya çıkar.

Teknik borç nasıl ölçülür ve yönetilir?

Teknik borç, bilinen kısayolların ve düzeltme ihtiyaçlarının bir borç listesinde kayıt altına alınması, her kalemin etkisinin ve düzeltme maliyetinin tahmin edilmesi, geliştirme kapasitesinin belirli bir bölümünün düzenli olarak bu listeye ayrılması ve borcun büyüme eğiliminin izlenmesiyle yönetilir. Ölçü kesin bir rakam değil, eğilimdir.

Borç listesi, iş isteklerinin tutulduğu aynı yerde tutulmalı ve önceliklendirmeye girmelidir. Yönetici bu listeyi görebilmeli, 'şu modülde şu kısayol var, düzeltmesi şu kadar, düzeltilmezse şu risk var' bilgisi teknik olmayan dille yazılmalıdır. Böylece borç ödeme kararı bir teknik kapris değil, bir iş kararı olur.

Kod kalitesi araçları, test kapsamı ve derleme süresi gibi ölçütler de eğilimi izlemeye yardım eder; ancak en anlamlı gösterge, benzer büyüklükteki işlerin zaman içinde ne kadar sürdüğüdür. Bu süre uzuyorsa borç büyüyor, sabit ya da kısalıyorsa yönetiliyor demektir.

Teknik borç nasıl ödenir?

Teknik borç, geliştirme kapasitesinin düzenli bir bölümünü iyileştirmeye ayırarak, en yüksek faizli borçtan (en sık dokunulan ve en çok yavaşlatan bölümden) başlayarak, her yeni geliştirmeyle birlikte dokunulan alanı biraz daha temizleyerek ve büyük yeniden yazımlardan mümkün olduğunca kaçınarak ödenir. Bir kerede sıfırlamak yerine sürekli küçük ödemeler daha güvenlidir.

'Her şeyi baştan yazalım' teklifi cazip gelir ama çoğu zaman en riskli yoldur. Yeniden yazım, eski sistemin yıllar içinde biriktirdiği görünmez iş kurallarını da yeniden keşfetmeyi gerektirir; süre uzar, bu arada eski sistem de yaşatılmak zorundadır. Kademeli yaklaşım, sistemi parça parça yenilemek ve her parçayı çalışır halde devreye almak, çoğu durumda daha ekonomiktir.

Borcun tekrar birikmesini önlemek için üç alışkanlık yeterlidir: her değişiklikte kod incelemesi, kritik akışlar için otomatik test ve belgelemenin geliştirmenin parçası sayılması. Bu üçü bakım anlaşmasının ve geliştirme sözleşmesinin parçası yapıldığında, borç bir sürpriz olmaktan çıkıp yönetilen bir kalem olur.

Rezon ile teknik borcu yönetmek

Rezon, şirketlere özel CRM, ERP ve bayi portalı sistemleri kuran, kendi SaaS ürünlerini canlıda işleten İstanbul merkezli bir yazılım çözümleri şirketidir. Kendi ürünlerimizi yıllardır canlıda işletiyor olmamız, teknik borcun faizini birebir ödemiş bir ekip olduğumuz anlamına gelir; bu yüzden özel projelerde kod incelemesi, otomatik test ve belgeleme geliştirmenin parçasıdır, borç listesi müşterinin görebildiği bir yerde tutulur ve bakım anlaşmalarında düzenli iyileştirme payı bulunur.

Elinizde 'artık kimsenin dokunmak istemediği' bir sistem varsa, önce bir değerlendirme yaparız: borç nerede, ne kadar, kademeli mi yenilenmeli yoksa belirli bir bölüm mü yeniden yazılmalı. Çözümler sayfamızdaki özel yazılım bölümünde bu yaklaşımı görebilir, iletişim sayfamızdan mevcut sisteminizi kısaca anlatabilirsiniz; ilk değerlendirme görüşmesi ücretsizdir.