Yazılım Krizi

Yazılım Krizi

• Yazılım krizi nedir?

  • "Yazılım krizi" terimi ilk kez 1968'deki ilk NATO yazılım mühendisliği konferansında kullanıldı
  • Bu konferanslar, programlama pratiklerini tanımlayıp sistematik hale getirmeye yönelik ilk çabalardan biriydi
  • Son NATO yazılım mühendisliği konferansı, 1969'daki Apollo 11 fırlatmasıyla aynı dönemde yapıldı

• Yazılım krizinin nedenleri

  • 1972 Turing Ödülü sahibi Edsger Dijkstra, yazılım krizinin nedenini donanımın karmaşıklığı ve hızındaki artışla açıkladı
  • "Makineler daha güçlü hale geldikçe programlama sorunları da büyür" - Edsger Dijkstra

• Günümüzdeki yazılım krizi

  • Bugün yazılım krizinden artık pek söz edilmiyor
  • Yeni dillerin ve organizasyon yöntemlerinin geliştirilmesiyle sorunun çözüldüğü düşünülüyor
  • Ancak bu, gerçek bir rahatlıktan çok yenilgi ve kabullenme duygusundan kaynaklanıyor olabilir

• Soyutlama sorunu

  • Yazılım krizini çözmek için çeşitli girişimler oldu, ancak bunların çoğu sorunu "soyutlama" yoluyla çözmeye çalıştı
  • Soyutlama, performans bedeli karşılığında belli ölçüde bağımsızlık sağlar
  • Kişisel bilgisayarların ticarileşmesinden sonra soyutlama temel düşünme biçimi haline geldi

• Geliştiriciler ile kullanıcılar arasındaki uçurum

  • Yazılım krizi, yalnızca yazılım üretenleri değil onu kullananları da etkiler
  • Kullanıcılar, yazarın sundukları dışında neredeyse hiçbir şeyi kontrol edemez
  • Alan Perlis: "İyi bir fikriniz varsa sorumluluğunu üstlenmeye de hazır olmalısınız"

• Sorumluluğun yokluğu

  • Yazılım üreticileri, yaptıkları araçların sorumluluğundan uzak duruyor
  • Ticarileşmeyle birlikte bu eğilim daha da güçlendi
  • Soyutlama, zor düşünmekten kaçınmanın bir aracı olarak kullanılıyor

• Çözüm

  • Yazılım krizinin çözümü, daha kısıtlı platformlara geri dönmek değil; soyutlama katmanlarının sayısını sınırlamak ve bilginin korunmasını zorunlu kılmaktır
  • Programlama modelleri, kullanıcı arayüzleri ve temel donanım sığ ve birleştirilebilir olmalıdır
  • Araçların kullanıcılarına yetki verilmelidir

• Bugünkü hareketler

  • Handmade, Permacomputing ve retro bilişim gibi, yazılım krizine dair farkındalığı artırmaya çalışan hareketler var
  • Bu karşı-kültürel hareketler sağlıklı bir işaret ve durumun daha iyiye gidebileceğini gösteriyor

GN⁺ Özeti

• Yazılım krizi, donanımın karmaşıklığı ve hızındaki artıştan kaynaklanan bir sorundur
• Günümüzde sorun soyutlama yoluyla çözülmeye çalışılıyor, ancak bunun bir performans bedeli var
• Yazılım üreticileri, yaptıkları araçların sorumluluğundan uzak duruyor ve bu durum ticarileşmeyle daha da güçleniyor
• Çözüm, soyutlama katmanlarının sayısını sınırlamak ve bilginin korunmasını zorunlu kılmaktır
• Handmade ve Permacomputing gibi hareketler, yazılım krizine dair farkındalığı artırıyor

[GN⁺]

Hacker News görüşleri

• Yazarın görüşü

  • Soyutlamanın kendisine değil, sınırsız uygulanmasına karşı çıkıyor
  • Çözüm olarak daha kısıtlı platformlara geri dönülmesini savunmuyor
  • Kullanıcıların "daha teknik" olması gerektiğini öne sürmüyor
  • Yazılım krizini anlamak için "platform yetkinliği" ile "büyüme/sürüm döngüsü" eğrilerini anlamak gerektiğini söylüyor
  • Bu yazının clickbait olmadığını, geliştirici olarak içinde bulunduğu durumu yansıttığını belirtiyor
  • Sorunun çözümüne kısmen katkı sunmak istediğini ve devam yazıları planladığını söylüyor

• Yazılım krizi

  • Proje bütçesinin aşılması, takvimin sarkması, verimsiz yazılım, düşük kalite, gereksinimlerin karşılanmaması, bakım zorluğu ve yazılımın hiç teslim edilmemesi gibi sorunları içeriyor
  • Başarılı yazılımlar göz ardı edilirken yalnızca başarısızlıklar ve kusurlar dikkat çekiyor
  • Bilgisayarların masaüstüne ulaşması için yüzlerce soyutlama katmanından geçmesi gerekiyor ve bu dünya genelinde her gün milyarlarca kez yaşanıyor

• Yazılım geliştirme ve liderlik

  • Otomotiv şirketlerinde liderlik teknik bilgiyi önemserken, çevik yazılım geliştirmede teknik yetkinlik alt kademelerde kalıyor
  • Yazılım geliştiriciler felsefi değerlendirmeler olmadan ticket bazında çalışıyor ve liderlik rollerine terfi etmiyor
  • Yazılım krizine dair farkındalığın bir hobi alanıyla sınırlı kalma ihtimali yüksek

• Soyutlamanın gerekliliği

  • Soyutlama vazgeçilmez bir araç; sorun kötü soyutlamalar ya da aşırı soyutlama
  • Yazılım geliştirme daha kolay hale geldi ve dokümantasyon da iyi durumda

• Araçlar ve bilgi

  • Doğru araçları biliyorsanız yazılım geliştirme oldukça kolay
  • Çoğu kişinin bildiği araçlar iyi değil ve bunda sermayenin etkisi büyük
  • Örneğin serverless bir ortamda karmaşık bir marketplace uygulamasını 3 saatte kurduğu bir video hazırlamış ama az izlenmiş

• GUI ve birleştirilebilirlik

  • UNIX araçlarını kullanırken yüzeysel ama birleştirilebilir bir deneyim yaşanıyor
  • GUI'ler birbiriyle iletişim kurmuyor ve birleştirilebilir değil
  • GUI ile shell pipeline'larını birleştiren araçlar üzerinde deneyler yapıyor

• Yazılımın önemi

  • Yazılımların çoğu kritik değil; kalite düşük olsa bile büyük bir sorun yaratmıyor
  • Yazılım geliştiricilerin çoğu Silicon Valley benzeri bir motivasyon olmadan çalışıyor

• Modülerlik ve soyutlama

  • İnternet gibi karmaşık sistemler katmanlı soyutlamalar sayesinde ayakta kalıyor
  • Yazılım araçları 70'lerden bu yana büyük ölçüde iyileşti
  • Örneğin VSCode Copilot kullanıldığında tüm API otomatik tamamlanabiliyor

• Proje yönetimi krizi

  • Yazılım krizinden çok bir proje yönetimi krizi var
  • Planlayanlarla teslim edenler arasında bir kopukluk bulunuyor
  • Yazılım geliştirmenin ticarileşmesi, farklı seviyelerde insanın bu alana katılabilmesini sağlıyor
  • Bu durum gıda sektörüne benziyor; buna "restoran krizi" denmiyor