Teknik borç (technical debt) software development’in kaçınılmaz realitesi. Her kısayol, her deadline baskısı biraz borç ekliyor. Developer biliyor ama yöneticiyle konuşmak zor. “Refactor’a zaman ayırmalıyız” argument’ı genelde satılmıyor.
19 yıldır farklı takımlarda bu konuşmayı yaptım. İyi yaptığım, kötü yaptığım zamanlar var. Bu yazıda pratik yaklaşımı paylaşacağım.
Yöneticinin perspektifi
Önce empathy. Yöneticinin duyduğu “teknik borç” genelde şunu demek:
- “Developer refactor yapmak istiyor”
- “Output azalacak”
- “Deadline kayması”
- “Net business value yok”
Bu algıyı kırmadan ilerleme mümkün değil.
Business dil kullan
Teknik terminoloji developer’ı rahat ettiriyor ama yönetici için gürültü. Teknik borcu business impact’e çevir:
Developer dili: “UserService class’ı 2000 satır, SOLID principles’a uymuyor, refactor lazım.”
Manager dili: “Yeni feature eklemek için 1 hafta yerine 3 hafta sürüyor. Önümüzdeki quarter 2 feature yerine 5-6 ekleyebilmek için bu zaman yatırımı gerekiyor.”
Aynı problem, farklı framing.
Measurable metric’ler
Opinion yerine data.
Metric’ler:
1. Velocity trend. Son 6 ay’da team velocity düşmüş mü? Teknik borç göstergesi.
2. Bug rate. Son 3 ayda production bug artıyor mu? Quality düşüşü.
3. Deploy frequency. Weekly deploy’dan bi-weekly’e düştü mü? Risk aversion.
4. Feature time to market. Aynı kompleksitedeki feature 2 hafta yerine 4 haftada çıkıyor mu?
5. Onboarding time. Yeni dev’i productive hale getirmek 1 ay’dan 2 aya mı çıktı?
Bu metric’leri kayıt et. Trend oluşturunca manager görüyor.
Specific ask
Vague talep kabul edilmiyor. “Teknik borç için zaman lazım” → sonuçsuz.
Specific ask:
“Önümüzdeki quarter velocity’sinin %15’ini teknik borç için ayırıyoruz. Focus: UserService refactor + test coverage %40’tan %70’e. Expected outcome: Q4’te feature throughput %30 artış.”
Measurable, time-boxed, outcome-focused. Manager anlayabiliyor ve onaylayabiliyor.
Hikayeyle satış
Concrete example’lar soyut argument’tan güçlü.
Abstract: “Code quality düşüyor.”
Concrete: “Geçen ay checkout’a ‘Apple Pay’ eklemek 3 sprint sürdü. 2 yıl önce ‘Stripe’ eklemek 1 sprint sürmüştü. Aynı kompleksite, 6x süre. Code base kaldıramıyor.”
Hikaye yöneticinin empathize etmesini sağlıyor.
Refactor vs rebuild
Refactor bazen overkill olur, rebuild lazım. Karar zor.
Refactor seç:
– Business logic çoğunlukla doğru
– Test coverage var
– Problem code organization’da
– Incremental iyileştirme mümkün
Rebuild seç:
– Kritik design flaw
– Tech stack outdated
– Security fundamental concerns
– Incremental fix hiçbir yere varmıyor
Rebuild daha costly (3-6 ay), refactor ongoing (slice-by-slice, feature’larla paralel).
Incremental improvement
“Big bang refactor” nadir başarılı. Incremental yaklaşım:
Boy Scout rule: Dokunduğun kodu girdiğinden temiz bırak. Her PR’da küçük iyileştirme.
Feature area refactor: Feature üzerinde çalışırken o feature’ın code area’sını refactor et. Business justification var.
Dedicated %X time: Each sprint %15-20 technical work. Bug fix + refactor + small improvements.
Bu yaklaşımlar manager’a “yeni feature’ı yapamayacağız” demiyor. Her sprint hem feature hem improvement.
Risk framing
Teknik borç riski yönetici için tangible:
Security risk: Eski framework, bilinen CVE’ler. Hack riski.
Scaling risk: User 10K’ya ulaşırsa sistem çökecek. Growth opportunity kaybı.
Hiring risk: Kimse bu eski stack’te çalışmak istemiyor. Talent acquisition zor.
Compliance risk: GDPR, KVKK, PCI-DSS gereksinimlerini eski sistem karşılamıyor.
Bu 4 risk kategorisi manager için alarm triggering.
ROI calculation
Teknik borç yatırımının ROI’sini hesapla:
Example:
– Teknik borç işi: 4 sprint (2 ay, 2 developer) = 4 person-month
– Expected return: her feature 50% faster → Q4’te 10 sprint kazancı
– ROI: 10 sprint kazanç / 4 sprint yatırım = 2.5x
Bu kind of calculation yönetici dili. Approve etmeyi kolaylaştırıyor.
Technical debt register
Every team için bir “debt register”:
| Item | Impact | Effort | Priority |
|——|——–|——–|———-|
| UserService refactor | High | 2 sprint | 1 |
| Legacy payment module | Med | 1 sprint | 2 |
| Test coverage | High | Ongoing | 1 |
| Old jQuery dependency | Low | 3 sprint | 3 |
Görünür olunca priority oluşturmak kolaylaşıyor. Her retro’da review.
“No” said, what next?
Yönetici refactor için zaman vermiyor. Ne yapacaksın?
Option 1: Compliance. Short-term feature’ları delivery et, debt biriksin. Bir süre sonra velocity kritik düşerken daha güçlü position.
Option 2: Stealth refactor. Her feature’da ilgili alanı iyileştir. Boy Scout rule’u aggressive uygula.
Option 3: Document risks. Formal email, “bu risk’ler var, şu iyileştirmeler gerekli”. Manager onaylamazsa responsibility şift.
Option 4: Escalate. Direct manager yetmiyorsa skip level. VP, CTO ile konuş.
Stealth refactor genelde işe yarıyor. Agresif compliance genelde burnout.
Success story example
Bir projede checkout refactor satışı:
Situation: Checkout 5 yaşında, 3 farklı developer dokunmuş, kimse anlamıyor. Her feature eklenmesi 2x uzun sürüyor.
Pitch to manager:
“Son 6 ay’da checkout feature’lar velocity %40 düştü. Bug rate %80 arttı. Kullanıcı feedback’inde ‘1.5x daha yavaş’ yorumlar.
Öneriyorum: 6 hafta sürekli refactor. 2 developer. Sonunda:
– Velocity %50 recovery (Q2 ortasından başlayarak)
– Bug rate normale dönüş
– Test coverage 40%’tan 75%’e
– Yeni dev onboarding 3 hafta’dan 1 hafta’ya
ROI: 6 sprint yatırım, Q3’ten itibaren ayda 3 sprint tasarruf.”
Result: Approved. Refactor yapıldı. Metric’ler tahmini doğruladı.
Sonuç
Teknik borç konuşması success’i comes from manager perspective + business language + concrete metrics + specific ask.
Opinion yerine data. Effect description yerine business impact. Vague talep yerine measurable plan.
Bu disciplin ile çoğu manager anlayışla karşılıyor. Anlamayan manager ile çalışıyorsan organization problem var, debt problem değil.