Bir yazılım projesinin toplantı odasında duyabileceğiniz en tehlikeli, en pahalı ve felaketi en garantili kılan cümle şudur:

"Arkadaşlar, bu mimari üzerinde son altı aydır gece gündüz çalışıyoruz. Tam on bin satır kod yazdık, onlarca test hazırladık. Şimdi kalkıp da 'bu yaklaşım yanlışmış, hepsini çöpe atıp baştan başlayalım' diyemeyiz. Bu kadar emeği heba edemeyiz; elimizdekini toparlayıp canlıya çıkmak zorundayız."

Bu sözler dile getirildiği anda, mantık kapıdan dışarı çıkmış ve sahneyi insan psikolojisinin en kadim tuzaklarından biri olan "Sunk Cost Fallacy" (Batık Maliyet Yanılgısı) devralmıştır.

Geliştiriciler ve yöneticiler; harcanan zamanı, dökülen alın terini ve uykusuz geceleri birer "onur madalyası" gibi görerek yanlış bir karara körü körüne sarılırlar. Oysa evrenin ve matematiğin en temel kuralı son derece nettir: Geçmişte harcadığınız kaynaklar geri getirilemez; gelecekte vereceğiniz kararlar ise sadece o andan itibarenki fayda ve maliyete göre verilmelidir.

Yanlış yöne giden bir trene bindiyseniz, biletinize ne kadar para ödediğinizin veya trende kaç saat yolculuk ettiğinizin hiçbir önemi yoktur. Son durağa kadar gidip uçurumdan yuvarlanmak istemiyorsanız, ilk istasyonda inmek zorundasınızdır.

Tıpta Yanlış Teşhis ve Tedavide İnat Etmek

Bu psikolojik körlüğün acil servisteki veya yoğun bakımdaki yansıması ölümcüldür.

Bir hastaya nefes darlığı ve göğüs ağrısıyla geldiğinde ilk etapta "pnömoni" (zatürre) teşhisi koyduğunuzu ve yüksek doz antibiyotik tedavisine başladığınızı düşünün. Aradan 48 saat geçmiştir. Hastanın akciğer sesleri düzelmemekte, oksijen saturasyonu düşmekte, bacaklarında ödem gelişmekte ve kardiyak enzimleri yükselmektedir.

Tablo bas bas bağırmaktadır: "Bu hasta zatürre değil, kalp yetmezliğine bağlı Akut Akciğer Ödemi tablosunda!"

Şimdi bir an için o hekimin şöyle düşündüğünü hayal edin: "İki gündür bu hastaya en pahalı antibiyotikleri verdik, tedavi planını sisteme böyle girdik, dosyasına zatürre yazdık. Şimdi kalkıp da kalp yetmezliği tedavisine dönersek iki günlük emeğimiz ve harcadığımız ilaçlar çöpe gider. Biz antibiyotiğin dozunu biraz daha artıralım, belki işe yarar."

Böyle bir hekim hastasını göz göre göre öldürür.

Tıpta en saygıdeğer refleks, "Teşhisim yanlıştı, hemen rotayı değiştiriyorum" diyebilmektir. Hekimlik egosu, hastanın yaşam hakkının önüne geçemez. Yeni klinik veriler hipotezinizi çürüttüğü an; o ana kadar verdiğiniz tüm serumları keser, gerekiyorsa hastanın kalbini rahatlatacak diüretikleri ve vazodilatatörleri anında devreye sokarsınız. Çünkü tıpta geçmişe takılıp kalanlar sadece mezarlıkları büyütür.

Bataklığı Büyüten On Bin Satır

Yazılım dünyasında ise ne yazık ki kod silmek, kod yazmaktan çok daha zor bir psikolojik eşiktir.

Bir mühendis ekibi düşünün. Altı ay önce popüler bir mikroservis mimarisini veya karmaşık bir event-sourcing modelini benimsemişlerdir. İhtiyaçları olmadığı halde Kafka kuyrukları kurmuş, CQRS yapılandırmış, distributed transaction'lar için Saga pattern'leri yazmışlardır.

Sistem büyüdükçe anlaşılır ki; veritabanı tutarlılığı sağlanamamakta, ağ gecikmeleri sistemi felç etmekte ve basit bir kullanıcı kaydı bile 15 servisin onayından geçmek zorunda kaldığı için sürekli patlamaktadır. Aslında ihtiyaç duyulan tek şey, Postgres üzerinde çalışan sade, monolitik ve transactional bir mimaridir.

Fakat ekip masaya oturduğunda kimse o on bin satırı silmeye cesaret edemez. Çünkü o kodları silmek, son altı ayın bir hata olduğunu, harcanan şirket bütçesinin boşa gittiğini ve mimari vizyonun iflas ettiğini itiraf etmek demektir.

Bunun yerine ne yapılır?

Patlayan kuyrukları kurtarmak için araya yeni retry servisleri yazılır (+1.500 satır).
Tutarsız verileri gece tarayıp düzelten karanlık cron script'leri eklenir (+2.000 satır).
Servislerin ayağa kalkma sırasını yönetmek için karmaşık bash script'leri döşenir (+500 satır).

Yani bataklığa batmış bir sistemi kurtarmak adına, bataklığın içine 4.000 satır daha beton dökülür! Sonuçta sistem biraz daha ağırlaşır, biraz daha karmaşıklaşır ve kaçınılmaz çöküş anı sadece birkaç ay ertelenmiş olur.

En İyi Kod, Henüz Yazılmamış Olandır

Büyük mühendisleri ortalama mühendislerden ayıran en temel fark, koda duydukları duygusal bağın derecesidir.

Kıdemsiz bir yazılımcı yazdığı koda aşık olur. Onu çocuğu gibi sever; her fonksiyonunu, her değişken ismini bir sanat eseri gibi korur. Birisi kodunu silmek veya refactor etmek istediğinde kişisel bir hakarete uğramış gibi hırçınlaşır.

Oysa bilge bir mühendis bilir ki; kod bir varlık (asset) değil, bir yükümlülüktür (liability).

Yazdığınız her satır kod; gelecekte bakım yapılması gereken, güvenlik açığı barındırma potansiyesi olan, test edilmesi gereken ve işletim sistemi güncellendiğinde kırılma riski taşıyan bir borçtur. Bir sistemi 10.000 satır kodla çözmek bir başarı değildir; aynı sistemi 200 satır sade bir mantıkla çözebilmek gerçek zekadır.

Ve gerektiğinde, hiçbir pişmanlık duymadan o 10.000 satırı git rm komutuyla tarihin çöplüğüne gönderebilmek, bir yazılımcının erişebileceği en yüksek mesleki olgunluk seviyesidir.

Çöpe Atma Cesareti

Eğer bir projede işler sarpa sarmışsa, her yeni özellik eklenişinde başka bir yer kırılıyorsa ve mimari artık ekibin ayağına dolanan bir prangaya dönüşmüşse; kendinize şu soruyu dürüstçe sorun:

"Bugün bu projeye sıfırdan başlasaydık, mevcut bilgimiz ve tecrübemizle bu mimariyi tekrar tercih eder miydik?"

Eğer bu sorunun cevabı net bir "Hayır" ise; o ana kadar kaç yüz saat harcadığınızın, kaç bin satır kod yazdığınızın hiçbir hükmü yoktur.

O kodu çöpe atın.

Hatalarınızı kabul edin. Yanlış yolda koşarak doğru hedefe varamazsınız. Harcanan zaman zaten harcanmıştır; onu geri alamazsınız. Ancak geleceğinizi, akıl sağlığınızı ve projenin kaderini kurtarmak hala sizin elinizdedir.

Çünkü gerçek ustalık, ne zaman inşa edeceğini bilmek kadar, ne zaman yıkıp temiz bir sayfayla baştan başlayacağını bilmektir.

sunk-cost

"Sunk Cost Fallacy": Yanlış Yolda 10,000 Satır Kod Yazmak