Agile yazılım inovasyonunu öldürüyor

• Black Hat konferansında Signal'in kurucusu Moxie Marlinspike, çevik geliştirme nedeniyle son 20 yılda yazılım inovasyonunun ortadan kaybolduğunu savundu
• Geliştiricilerin "kara kutu soyutlama katmanları" içine hapsolduğunu ve inovasyon için gerekli özgürlüğü kaybettiğini belirtti
• "Mühendislik organizasyonlarını yöneten hemen herkes ya çevikliğin alt kavramı olan, ya ondan türemiş, ya çevikliğin alanına giren ya da bir şekilde onunla ilişkili bir yönetim felsefesine sahip"
  • Geliştiricilerin mühendislik uzmanlığını mevcut teknolojinin yeni yeteneklerini görebilen bir vizyonla birleştirerek aşağıdan yukarıya ilerlemesi yerine,
    Agile ekiplerinin ayrı ayrı silo'lara bölündüğünü, birbirlerinden kopuk çalıştığını ve diğer ekiplerin ne yaptığını anlayamaz hale geldiğini ileri sürdü
• Ayrıca kapanış oturumunda Thistle Technologies'in kurucusu ve CEO'su Window Snyder, bu tür kara kutu ekiplerin kendi ürünlerinin çalışma prensiplerine dair görünürlüğünün de zayıf olma eğiliminde olduğunu ekledi
  • Snyder ayrıca, programlama öğrenen öğrencilerin düşük seviyeli diller veya makine koduyla etkileşim kurmayı değil, uygulama geliştirmeyi kolaylaştıran yüksek seviyeli dilleri öğrendiğini; bu yüzden mühendislerin yapboz parçalarının birbirine bağlı daha büyük bütün içine nasıl oturduğunu anlaması için gerekli bağlamdan yoksun kaldığını savundu

Güvenlik araştırmacıları inovasyonun anahtarını elinde tutuyor

• Marlinspike ayrıca, son birkaç on yılda yazılım mühendisliğinin daha hızlı, daha esnek ve daha ileri gitmek için soyutlandığını; buna karşılık güvenlik araştırmacılarının ise soyutlamanın ötesini görmeye çalıştığını söyledi
  • "Güvenlik, soyut olanın içine bakıp onun gerçekte nasıl çalıştığını, altında ne olduğunu ve bazen bunu ilk yapan kişiden bile daha iyi anlamaya yönelik bir süreçtir"
• Bu nedenle güvenlik araştırmacılarının yeni inovasyonları tetikleyecek anahtarı elinde tuttuğunu savundu
• Yazılımı anlamayı büyüyü anlamaya benzetti ve güvenlik uzmanlarını da "kütüphanede oturup büyü çalışan insanlar" olarak niteledi

GN⁺ görüşü

• Bu, Marlinspike'ın çevikliğin temel sorunlarını keskin biçimde işaret eden içgörülü bir değerlendirmesiydi
• Soyutlamaya ve hızlı geliştirme temposuna aşırı odaklanıldıkça geliştiricilerin temel kavramlardan giderek uzaklaşması tespiti yerinde görünüyor
• Güvenlik araştırmacılarının rolüne dikkat çekmesi etkileyiciydi; güvenlik, soyutlamanın arkasına gizlenmiş gerçek yapıyı açığa çıkardığı için inovasyonun itici gücü olabilir
• Bir bakıma bu, yazılım mühendislerinin daha derin bir anlayış peşinde koşması gerektiği mesajını veriyor
• Elbette çevikliğin güçlü yanları da var; bu nedenle dengeli bir yaklaşım gerekli görünüyor. Çevikliğin hızını ve esnekliğini korurken temelleri sağlamlaştıracak yollar aranmalı
• Bunun için geliştirme eğitiminden başlanarak iyileştirme yapılması gerekiyor. Yalnızca yüksek seviyeli diller değil, düşük seviyeli diller, bilgisayar mimarisi gibi temel dersler de güçlendirilmeli

[jeokrang]

Görünüşe göre çevikliği yanlış anlayan yöneticilerin sorunları, çevikliğin kendi sorunu sanılıyor.

[yangeok]

Sanırım zamanın akışına uyup düşük seviyeli bilgileri öğrenmenin ROI’si kalmadığı için sadece yüksek seviyeli bilgileri öğrenmekle yetiniyoruz.

[andrewchaa]

Neden durup dururken Agile'a yükleniliyor ki ...

[lordang]

north-south ile east-west kavramlarını birbirine karıştırarak anlatmış, o yüzden içerik kafa karıştırıcı.
Başka ekibin ne yaptığını bilmemek, Agile'ın kendisinden çok cross-functional organizasyon yapısının daha büyük bir sorunu değil mi diye düşünüyorum.

low level hakkında çok şey bilinmemesi konusunda ise, metne bakınca "öyle olunca low levelı da iyi bilmeme eğilimi oluyor" gibi bir şey söylüyor.

Diğer ekiplerin ne yaptığını bilmemenin biraz da olsa Agile'la ilişkili olduğunu varsaysak bile, low level bilmemekle Agile'ın ne ilgisi var, gerçekten anlayamıyorum hahaha

[lordang]

Sıkı yorumlarsak, aslında daha doğru açıklama şu olabilir: açık kaynak yaygınlaştıkça artık her şeyi bizzat yapmaya gerek kalmadı, bu yüzden reinventing wheel yapılmıyor; low-level tarafta da her şey hazır alınıp kullanıldığı için insanlar özellikle gidip çalışmıyor.

O sözü illa anlamlandırmaya çalışırsak, "Agile yüzünden sadece hızlı yapmak hedefleniyor, bu yüzden low-level çalışılmıyor" diye yorumlanabilir belki; ama bence asıl doğru olan, ihtiyaç olmadığı için yapılmıyor demek.

[bbulbum]

Bence Agile, sorunlara geniş bir perspektiften bakmayı ve uzun vadede sürdürülebilir olmayı sağlayan tercihleri giderek geri plana itiyor; bu da yazılım açısından yalnızca gözümüzün önündeki sorunları çözmeye odaklanmaya yol açıyor.
El yordamıyla önce çalışır hale getirmek Agile olmak değildir elbette, ama hız odaklı seçimler yapma eğiliminin ortaya çıktığını düşünüyorum ve bunun derin bir anlayış geliştirmeyi zorlaştıran bir etken olabileceğini düşünüyorum.

[savvykang]

Mühendislik organizasyonlarında karar alma yetkisinin olmaması sorununun nedenini neden Agile'da aramaya çalıştıklarını anlamıyorum

[galadbran]

Diğer ekiplerin ne yaptığını bilmemekle çevik yaklaşımın ne ilgisi var ki... ;;;

Ama doğrusu, Window Snyder adı oldukça ilginçmiş...

[xguru]

Sanırım orijinal videoyu izlemek istiyorum ama henüz yok. Çok geçmeden resmi YouTube kanalına yüklenir diye düşünüyorum
https://www.youtube.com/@BlackHatOfficialYT/

[GN⁺]

Hacker News görüşü

• Modern şirket yapısı sorunun kökeni

  • Sorumluluk ve karar almanın şirket hiyerarşisi boyunca yukarı çıkması gerektiğini söyleyen modern bir yönetim teorisi var
  • Alt kademedeki çalışanların ürün hakkında en az bilgiye sahip olduğu varsayılıyor
  • Ancak gerçekte en çok bilgiye sahadaki çalışanlar sahip
  • Yazılım mühendisliğini bir montaj hattı sürecine dönüştürürseniz inovasyon durur
  • Eşitlikçi bir yönetim hiyerarşisi tek başına çözüm değil, ama sahadaki çalışanları etkisizleştirmeyen bir yönteme ihtiyaç var
  • <i>Reinventing Organisations</i> kitabı yenilikçi şirket yapıları hakkında açıklama yapıyor

• Agile'ın iyi fikirleri genel yazılım mühendisliğine emildi

  • Agile programcılarının katı stand-up toplantıları, Kanban panoları vb. takip ettiği düşünülüyor
  • Agile'ın bilginin bölünmesine ve yazılım mühendisliğinde beceri erozyonuna yol açtığını düşünmüyorum
  • Bu, kitlesel üretim eğiliminin yarattığı bir sorun
  • Benzer durumlar otomobil şirketlerinde ya da mobilya fabrikalarında da görülüyor

• Agile, Scrum ve OKR'lara yönelik memnuniyetsizlik

  • Bunların hepsi özgürlük ve sorumluluğu alt kademedeki çalışanlara verdiklerini vaat ediyor, ama pratikte merkezileşiyorlar
  • OKR'leri tersine uygulamayı denemek istiyorum
  • Her çalışanın kendi alanında temel sonuçları tanımlaması ve yöneticilerin buna dayanarak ekibin yönünü belirlemesi gerekir
  • Yukarıdan aşağıya değil, aşağıdan yukarıya bir yaklaşım gerekli
  • İyi işe almalı, iyi eğitmeli ve çalışanlara güvenmeliyiz

• Backlog refinement toplantısındaki deneyim

  • Aşina olmadığım bir koddaki bug düzeltmesini tahmin etmem gerekiyordu
  • Tahmin etmek zor olduğu için rastgele bir sayı söyledim
  • Agile üç farklı yerde de benzer şekilde işletiliyordu

• Agile'ın sorunlarına dair bir teori

  • İşleri küçük parçalara bölmek faydalı, ama programlamada yaratıcılık gerekiyor
  • İşi bölme sürecinde çok fazla bilgi kayboluyor
  • Geliştiricilerin yaratıcı çözümler bulması gerekiyor ama ihtiyaç duydukları bilgiyi alamıyorlar
  • Daha deneyimli geliştiricilere ya da daha iyi tasarım diyagramları ve dokümantasyona ihtiyaç var

• Yazılım kalitesindeki düşüş

  • Son birkaç on yılda yazılım kötüleşti
  • Daha güçlü makineler kullanıyoruz ama tepkisellik daha düşük
  • Bunun Agile'ın yükselişiyle bağlantılı olması mümkün

• Mühendislerin kodun bir bölümünü "sahiplenmesine" izin verilmeli

  • Bu, ekibin yazılımının en iyi olduğu dönemdi

• Günlük stand-up toplantılarından kaçınma deneyimi

  • Sürekli retrospektifler ve iş bölme verimsizdi
  • Yalnızca teknik olmayan yöneticilere fayda sağlıyordu

• Büyük ölçekli organizasyonların sorunu

  • Geliştiriciler artık liderlik etmiyor
  • Vizyon, ürün, UX ve proje yönetimi üst kademede belirleniyor
  • Geliştiriciler bulut teknolojilerini kullanarak görevleri yerine getiriyor
  • Büyük resmi anlayamıyor ya da önemli önerilerde bulunamıyorlar

• Yazılım geliştirmenin "büyüsünü" geri getirmek gerektiği görüşü

  • Kişinin 20 yıldan uzun süredir sektörde olduğu anlaşılıyor
  • Genç programcılarla zaman geçirince o büyünün hâlâ var olduğu görülüyor
  • 20 yıl önce de benzer şikayetler vardı ama yine de çalışmak eğlenceliydi

[savvykang]

> Sorumluluk ve karar alma süreçlerinin kurumsal hiyerarşi boyunca yukarı taşınması gerektiğini savunan modern bir yönetim teorisi var.

Bu, bürokratikleşmiş örgütlerin gösterdiği bir özellik değil mi?