Teknik borç: ne zaman ödemeli, ne zaman görmezden gelmeli?

Her kurucu yazılımcılardan "teknik borcu kapatmamız lazım" lafını duyar. Sonra aynı yazılımcılar "daha hızlı yayınlamamız lazım" der. İkisi de haklı. Mesele, ne zaman refactor edeceğinizi, ne zaman sallantılı temellerin üzerine inşa etmeye devam edeceğinizi bilmek.

Teknik borç özünde kötü değil. Bir araç. Doğru kullanırsanız, fikirleri aşırı mühendisliğe boğulmadan doğrulamanız için zaman kazandırır. Kötü kullanırsanız, A serisi yatırımdan altı ay önce tüm şirketinizi durdurur.

Karar çerçevesi

Kendinize sorun: Bu kod kritik yolunuzda mı?

Kod, temel değer önermenizi (müşterilerin gerçekten para ödediği özelliği) ayakta tutuyorsa refactor edin. Ayda iki kez kullandığınız bir yönetim paneliyse, bozuk kalsın. Bir müşterimizin işlemlerinin %12'sini kaybettiren ödeme akışını yeniden yazdık. Şirket içi raporlama aracı ise hâlâ yamalı bohça gibi çalışıyor. Gelir %40 arttı. Raporları dert eden olmadı.

3 ay kuralı

Ürün-pazar uyumunu (product-market fit) yakalamadan önce, önümüzdeki 90 gün içinde bozulmayacak hiçbir şeyi düzeltmeyin. Yakaladıktan sonra, en iyi mühendislerinizi bir haftadan uzun yavaşlatan hiçbir şeyi görmezden gelmeyin.

Birlikte çalıştığımız bir Y Combinator şirketi, lansmandan sonra 18 ay boyunca MVP mimarisiyle devam etti. 2 milyon dolarlık yıllık tekrarlayan gelire (ARR) ulaştı. Ardından işe alım imkânsız hale geldiği için her şeyi yeniden kurmaya 3 ay harcadı; kıdemli yazılımcılar kod tabanına dokunmak istemiyordu.

Borç pahalıya geldiğinde

Borcu ödemenin zamanı geldiğini şu durumlarda anlarsınız:

• Ekip hızı (velocity) %30'dan fazla düşüyor: Özellik geliştirmek 3 ay öncesine göre iki kat uzun sürüyorsa, borcunuzun faizi fazla yüksek demektir
• Hata/özellik oranı tersine dönüyor: Yeni şey geliştirmekten çok hata düzeltiyorsanız sınırı aşmışsınız demektir
• Yayın korkusu: Cuma günü sürüm çıkarmak sizi korkutuyorsa, testlerinizin ve altyapınızın elden geçmesi gerekiyor
• Yeni yazılımcının ekibe alışması 3 haftayı aşıyor: Yeni yazılımcılar aylar değil, günler içinde kod yayınlayabilmeli

Refactor bütçesi

Mühendislik zamanının %20'sini borca ayırın. Bir sprint ya da bir çeyrek değil: her hafta. İki yazılımcı mı var? Biri cuma öğleden sonrasını temizliğe ayırsın. On yazılımcı mı? İkisi tam zamanlı altyapı, test ve refactor üzerinde çalışsın.

Bu, ivmenizi öldüren "durup her şeyi baştan yapmamız lazım" anını önler. Adım adım temizlik, her şeyi baştan yazmaktan her zaman daha iyidir.

Gerçekten önemli olan

Bazı borçlar stratejiktir. Dağınık kodla hızlı yayınlamak, rakipler yetişmeden fikirleri doğrular. Bazı borçlar ise düpedüz tembellik. Testleri "sonra ekleriz" diye atlarsanız, sonunda elinizde iskambil kâğıdından bir kule kalır.

Akıllı kurucular teknik borcu, nakit yakma hızını (burn rate) takip ettikleri gibi takip eder. Ne kadar borçları olduğunu, kapatmanın neye mal olacağını ve vadenin ne zaman dolacağını bilirler. En iyi mühendislik ekipleri borcu görünür kılar: backlog'da ayrı etiketler, aylık incelemeler, önceliklendirme için net kriterler.

Sizin işiniz teknik borcu ortadan kaldırmak değil. Taşıdığınız borcun, size kazandırdığı hıza değdiğinden emin olmak.