Trilyonlarca dolar harcanmasına rağmen hâlâ başarısız olan dev yazılım projeleri
(spectrum.ieee.org)- Dünya genelinde BT harcamaları 2005'ten bu yana üç kattan fazla arttı, ancak büyük ölçekli yazılım projelerinin başarı oranı neredeyse hiç iyileşmedi
- Kanada'nın Phoenix bordro sistemi, Birleşik Krallık'ın Post Office Horizon sistemi, ABD ve Avustralya'daki sosyal yardım ve idari sistemlerde yönetimsel, örgütsel ve etik başarısızlıklar tekrar tekrar yaşandı
- Yapay zeka araçları veya copilot'lar bu sorunları çözemiyor; insan hayal gücü eksikliği, gerçekçi olmayan hedefler ve başarısız risk yönetimi hâlâ başlıca nedenler
- Legacy sistemlerin bakım maliyeti BT bütçelerinin %70-75'ini oluşturuyor; Agile ve DevOps'un benimsenmesi de örgütsel liderlik ve kültürel değişim olmadan yüksek başarısızlık oranlarıyla sonuçlanıyor
- Tekrarlanan yönetim hataları ve sorumluluktan kaçış toplumsal maliyeti büyütürken, şeffaflık, etik ve insan odaklı sistem tasarımı temel görevler olarak öne çıkıyor
Yazılım başarısızlıklarının süregelen sorunu
- Son 20 yılda BT harcamaları 1,7 trilyon dolardan 5,6 trilyon dolara çıktı, ancak yazılım başarı oranı durağan kaldı
- Başarısızlıklar ülke, sektör ve organizasyon türü fark etmeksizin görülüyor
- Başarısızlıkların toplumsal ve ekonomik maliyeti sürekli artıyor
- Yapay zekanın yönetim sorunlarını çözememesinin sınırları açıkça görülüyor
- Büyük projelerdeki karmaşık paydaş ilişkileri ve politik etkenleri yapay zekanın kontrol etmesi zor
- BT projelerinde zaten çok sayıda irrasyonel karar alındığından, yapay zekanın öğrenebileceği örnekler de sınırlı
- Başarısızlığın nedenleri arasında insan hayal gücü eksikliği, belirsiz hedefler, karmaşıklığın yönetilememesi ve risk kontrolünün olmaması yer alıyor
- On yıllardır aynı etkenler tekrarlandığı için bir tür “failure déjà vu” durumu sürüyor
Kanada Phoenix bordro sistemi
- 2016'da devreye alınan CA$310 milyonluk Phoenix sistemi, 80.000 bordro kuralı ile 105 sendika sözleşmesini birleştirmeye çalışırken başarısız oldu
- Bütçeden tasarruf etmek için test ve pilot süreçleri daraltıldı, temel işlevler çıkarıldı ve aşırı zorlayıcı adımlar atıldı
- Sonuç olarak 9 yıl içinde 430 bin çalışanın %70'i maaş hatası yaşadı
- Mart 2025 itibarıyla 349 bin hata hâlâ çözülemedi, bunların yarısından fazlası 1 yıldan uzun süredir bekliyor
- Çalışan intiharı vakaları bile rapor edildi
- Toplam maliyet 5,1 milyar CA$'ı aştı; Sayıştay bunu “proje yönetimi ve denetimindeki anlaşılmaz bir başarısızlık” olarak niteledi
Birleşik Krallık Post Office Horizon sistemi
- 1999'da kullanıma alınan Fujitsu'nun Horizon POS sistemi, iç hataları gizleyerek 3.500 şube müdürünün sahte muhasebe ve dolandırıcılık suçlamalarıyla yargılanmasına yol açtı
- 900 kişi mahkûm edildi, 236 kişi hapse girdi, 13'ten fazla kişi intihar etti
- Teknik, yönetimsel, hukuki ve etik başarısızlıklar birlikte etkili oldu
- Hatalarla dolu middleware, kontrolsüz kapsam genişlemesi, yetersiz test ve personel eksikliği
- Yöneticiler sorunları dile getirenlere karşı düşmanca davrandı, kanıtları gizledi ve kurumsal örtbas girişimlerinde bulundu
- 2016 ve 2021'deki değiştirme girişimleri de başarısız oldu; Horizon hâlâ kullanımda
- Yeni sistem için bütçe £410 milyon, kararın Temmuz 2026'da verilmesi planlanıyor
Diğer büyük başarısızlık örnekleri
- Minnesota MNLARS: 2016'da başladı, 2019'da iptal edildi, maliyet 100 milyon dolar
- Avustralya Modernising Business Registers: AU$480 milyonluk bütçe AU$2,8 milyara çıktı, 2022'de iptal edildi
- Louisiana araç tescil sistemi: 50 yıllık mainframe'in tekrar eden arızaları nedeniyle 2025'te olağanüstü hâl ilan edildi
- Jaguar Land Rover: 2025'teki siber saldırı nedeniyle küresel operasyonlar bir aydan uzun süre durdu, zarar 1,2-1,9 milyar dolar
- Lidl ERP: SAP tabanlı 500 milyon euroluk ERP başarısızlığının ardından şirket kendi sistemine geri döndü (2017)
- Boeing 737 Max: MCAS tasarım kusuru nedeniyle 346 kişi öldü, toplam maliyetin 74 milyar dolar olduğu tahmin ediliyor
- F-35 Block 4 yükseltmesi: takvim 5 yıl sarktı, maliyet 10,5 milyar dolardan 16,5 milyar dolara çıktı
Başarısızlığın ekonomik maliyeti
- ABD'de 2022 yazılım başarısızlığı maliyeti 1,81 trilyon dolar, geliştirme başarısızlıklarının maliyeti ise 260 milyar dolar
- Toplam tutar savunma bütçesinden (778 milyar dolar) daha büyük
- Legacy sistemlerin bakım maliyeti yıllık 520 milyar dolar ve BT bütçelerinin %70-75'ini oluşturuyor
- Değiştirme maliyeti yüksek ve başarısızlık riski büyük olduğu için yenileme erteleniyor
- NTT DATA 2024 raporu: Kurumların %80'i eski teknolojilerin inovasyonu engellediğini söyledi
- Yöneticilerin büyük bölümü legacy altyapının pazara yanıt vermeyi zorlaştırdığını düşünüyor
Agile ve DevOps'un sınırları
- Yinelemeli ve kademeli geliştirme yöntemleri yaygınlaşsa da başarısızlık oranları sürüyor
- Bazı raporlar Agile projelerde %65, DevOps'ta ise %90'a varan başarısızlık oranlarından söz ediyor
- Başarılı uygulama için liderlik, kurumsal disiplin, eğitim ve kültürel dönüşüm gerekiyor
- Ancak çoğu kurum bunu sürdüremiyor
Tekrarlanan yönetim hataları ve öğrenme eksikliği
- BT proje yöneticileri sık sık “bizim projemiz farklı” diyerek geçmiş başarısızlıklardan çıkarılan dersleri görmezden geliyor
- Kanada hükümeti, 1995'teki ilk bordro sistemi başarısızlığından çıkarılması gereken dersleri Phoenix'te de tekrarladı
- Başarısızlıkların çoğu yenilikçi denemelerden çok sıradan yönetim hatalarından kaynaklanıyor
- Bu durum “yaratıcı yıkım”dan çok “mali yıkım”a benziyor
- Yapay zeka tabanlı kamu sistemlerindeki başarısızlık örnekleri
- ABD'deki MiDAS işsizlik yardımı sistemi ve Avustralya'daki Centrelink Robodebt, hatalı algoritmalar nedeniyle yüz binlerce kişiyi haksız yere suçladı
- Hükümetler hataları kabul etme ve tazmin konusunda isteksiz davrandı
Sorumluluk, etik ve şeffaflık ihtiyacı
- Yapay zeka içeren sistemlerdeki opak karar alma süreçleri, vatandaş haklarının ihlal edilmesi riskini artırıyor
- AB, 'algoritmik kararlara açıklama hakkını' yasal güvence altına aldı
- Dünya genelinde otomatik sistemlerde şeffaflık ve hesap verebilirliğin bir insan hakkı olarak yerleşmesi gerektiği vurgulanıyor
- Yazılım sorumluluk yasası ve uzman lisanslama sistemi tartışmaları var, ancak hayata geçirilme olasılığı düşük görülüyor
- Daha gerçekçi alternatif, yöneticilerde dürüstlük, şüpheci düşünme ve etik muhakemenin güçlendirilmesi
- Risklerin açık biçimde görülmesi ve tedarikçilerin abartılı vaatlerine karşı dikkatli olunması gerekiyor
- Yapay zeka dahil tüm BT sistemlerinde insan odaklı tasarım ilkelerinin uygulanması vurgulanıyor
Sonuç: Tekrarlanan hataları durdurma zamanı
- Yazılım geliştirme doğası gereği karmaşık ve kırılgandır; küçük hatalar büyük sonuçlara yol açabilir
- Başarılı projeler için yeterli kaynak, liderlik ve hesap verebilirlik şarttır
- Kullanıcılar üzerindeki duygusal ve ekonomik zararı da hesaba katan bir maliyet değerlendirmesi yapılmalı
- 1968'deki “yazılım krizi”nden bu yana 50 yılı aşkın süredir aynı hatalar tekrarlanıyor
- “Yeni hatalar yapın”
“Herkes hata yapabilir ama yalnızca aptallar kendi hatalarında ısrar eder” - Romalı hatip Cicero
5 yorum
Hacker News görüşü
Yazının son bölümünde sunulan çözüm bana yetersiz geldi.
Bence asıl çözüm küçük başlamak ve gerçek üretim ortamında doğrulamak.
Örneğin ülke çapında bir maaş sistemi yapılacaksa, önce 50 kişilik küçük bir kasabada test edilmeli, hatalar giderildikten sonra giderek daha büyük şehirlere yayılmalı.
Küçük ölçekte sorunları çözmeden tek seferde ülke çapına çıkan bir yazılım geliştirme süreci diye bir şey yok.
İşlem hacmi düşüktü; bir sorun çıkarsa elle düzeltilebiliyordu ve PCI kurallarından kaçınabiliyorduk.
Gerçek mağaza dağıtımından önce bu şekilde test ettiğimiz için büyük bir sorun yaşamadan teslim tarihini tutturdik.
Eğer baştan müşteri mağazalarına dağıtılsaydı, vergi hesaplama hataları ya da performans sorunları büyük bir karmaşa yaratırdı.
Kademeli genişleme teknik borç biriktiriyor; sonunda kimse kod tabanının çekirdeğine güvenemediği için rewrite korkusuna kapılıyor.
WhatsApp gibi basit bir ürün bile olsa, en baştan büyük ölçeklenebilirlik düşünülerek mühendislik tasarımı yapılması gerekiyor.
Küçük ve başarılı sistemlerde böyle bir kişinin ortaya çıkması daha kolay; bu da hem kullanıcıların hem geliştiricilerin güvenini kazanıp kademeli büyümeyi mümkün kılıyor.
Büyük projelerin başarısız olma olasılığı yüksek olduğundan, İhtiyat İlkesi (Precautionary Principle) gereği küçük başlamak gerekiyor.
Hangi proje olursa olsun, bu tekrar döngüsü temeldir.
Küçük başla, modülerleştir ve sonra ölçekle diyor. Tesla’nın megafabrika örneği etkileyiciydi.
Teknoloji tarihini incelerken fark ettiğim şey şu: donanım sektörü geçmişteki başarı ve başarısızlıklardan ders alıyor ama yazılım sektörü bunu yapmıyor.
Çoğu geliştirici eski sistemleri söküp inceleyerek öğrenmiyor; her nesil aynı sorunları yeniden yaşıyor.
Geriye dönük değerlendirmelerde hep “geliştiriciler bir dahaki sefere neyi farklı yapmalı?” diye soruluyor, yöneticiler ise hiçbir sorumluluk almıyor.
Sonunda aynı sorunlar tekrar ediyor ve yük geliştiricilerin üstüne yıkılıyor.
Önceki kuşaklar sorunları stack’in alt katmanlarında çözerken, bugün sadece üst katmanlarda çözmeye çalışılıyor.
Sonuç olarak bir soyutlama kulesi yükseliyor; daha çok kaynak harcanıyor ama çıkan işlevler benzer kalıyor.
Şimdi de AI modellerinin üstüne bir yazılım katmanı daha eklenen bir döneme giriyoruz.
Hem deneyim hem karakter önemli; düşük ego ve sorun çözme odaklı düşünce biçimi şart.
Çoğu kişi projenin karmaşıklığını olduğundan az görüyor.
Ben yüksek lisans dönemimde TinyOS kaynak kodunu bir hafta boyunca okuyarak yapısını kavramıştım ve bu deneyim çok faydalı oldu.
Yabancı bir kod tabanını hızlıca anlayabilme yeteneği çok değerli.
Düzenli aralıklarla yeni diller ve framework’ler çıktığında, şirketler sürekli düşük ücretli yeni mezunları işe alabiliyor.
Bence yazılımın diğer mühendislik alanları gibi ele alınmamasının nedenlerinden biri de bu yapı.
Temelde bu bir programlama sorunu değil, yönetim beceriksizliği sorunu.
Çoğu projede iş gereksinimleri açık biçimde tanımlanmıyor; her şey tahmine dayalı ilerliyor.
Büyük kamu IT projelerinin neden başarısız olduğunu sözleşme yapısına ve teşviklere bakınca anlamak kolay.
Sorun, yetkinlikten çok saat bazlı danışmanlığa dayanan yapı.
Başarılı projelerde belirleyici olan teknoloji değil, kurumlar arası hizalanma (alignment) ve yetkinlik (competence).
Silikon Vadisi’ndeki yaş ayrımcılığının gerçek bir sorun olduğunu düşünüyorum.
Deneyim göz ardı ediliyor ve geçmişin dersleri hiç yansıtılmıyor.
Donanım sektörü ise mirasa saygı duyarken aynı zamanda yenilik peşinde koşuyordu.
Geçmişteki başarısızlıklardan ders alanların yeni şeyler deneyemeyeceğini düşünen bir bakış açısı da var.
Yazılım projeleri sonuçta insan başarısızlığı yüzünden çöküyor.
Kusursuz süreç ya da araçlardan daha önemli olan şey, motivasyon sahibi ve sorumluluk alan insanlar.
İnsanların işini düzgün yapması için hukuki sonuçlar (Consequences) olmalı.
Fiziksel inşaat projelerinde olduğu gibi, her aşamada bağımsız doğrulama ve sorumluluk tanımlanmalı.
Bu yüzden belli bir düzeyde risk alarak ilerlemek daha gerçekçi.
Başarılı projeler, duygusal zekâ ve liderlik sahibi birkaç kişinin sayesinde yürüdü.
Sonuçta yazılım mühendisliği insan problemidir.
Ama sektör hâlâ sorumluluktan kaçma ve modaların peşinden gitme döngüsünde.
Bu sorunlar sadece yazılıma özgü değil.
Auburn Dam, Columbia River Crossing, Big Dig gibi büyük altyapı projeleri de bütçe aşımıyla kötü şöhrete sahip.
İlk bütçe gerçekçi değilse, bu sadece maliyetin gerçeğe yaklaşması olabilir.
Bu yüzden küçük projelerden başlayıp kademeli büyüme yaklaşımı önemli.
Ben ne geliştiriciyim ne de PM, ama büyük ölçekli başarı örneklerini merak ediyorum.
Hastanede çalıştığım için sağlık alanından başarılı örnekler olursa daha da iyi olur.
The Phoenix Project’i okuyup Agile ve DevOps düşünce biçimini biraz anladım ama bunu pratikte uygulamak zor.
Küçük projelerde başarının tohumunu ekmek istiyorum.
Multics’in karmaşıklığına tepki olarak Ken Thompson’ın Unix’i 3 haftada bizzat yazması başlangıç noktasıydı.
İlgili yazıya bakabilirsiniz.
Conway’s Law, kilit personel riski, net sahiplik, test kültürü gibi unsurlar da şart.
Hepsinden önemlisi, “hayır” diyebilme cesareti gerekli.
healthcare.gov gibi, başarısız başladıktan sonra iyileşen örnekler de var.
IT topluluğunu suçlamadan önce, şirketlerin kısa vadeli kâr odaklı kültürüne bakmak gerek.
Güvenlik ve istikrar her zaman bütçe kesintilerinde ilk hedef oluyor.
Yöneticiler başarısız olsalar bile altın paraşütle ayrılıyor, sorumluluk ise geliştiricilere kalıyor.
Devlet de şirketlerin zayıf güvenlik vakalarını gerektiği gibi cezalandırmıyor.
Sonunda “AI, danışmanlar, dış kaynak” ile çözeriz türü alaycı bir gerçekçilik tekrar edip duruyor.
AI’a trilyonlar harcamak durumu düzeltmez, aksine daha da kötüleştirir.
Batı toplumları zaten istikrarsız ve aşırı sağa kayıyor.
Bir sonraki kriz yalnızca finansal bir çöküş değil, toplumsal bir çöküşe de dönüşebilir.
İnsanlığın krizlerle değil, anlayış yoluyla ilerleme ile yol alması gerekir.
İyi süreçler varsa çıktıyı büyütür, kötü süreçler varsa sorunları hızlandırır.
Sonuçta yön aynı kalır; değişen yalnızca hız olur.
Bu kadar uzun süredir düzeltilmediyse, sorun geliştirme teknolojilerinde ya da geliştirme ilkelerinde değil, bunu kabul eden operasyon tarafında olabilir mi...
Birleşik Krallık Posta Ofisi skandalının bir de dizisi var.
Mağdurlara hâlâ tazminat ödenmediği için süreç devam ediyor.
Son dönemdeki yerel örnekler arasında, Gyeonggi Kredi Garanti Vakfı'nın yeni nesil bilgi işlem sistemi kurulumunun başarısız olması aklıma geliyor.
https://v.daum.net/v/20251111165048155
Diğer ülkelerde de gerçekten çok büyük SI projeleri mi yürütülüyor?