Yazılımcılar olarak neden acı çekiyoruz?
Yazılım sektörü, her geçen gün işlerin teknik açıdan hem biraz daha kolaylaştığı ama aynı ölçüde zorlaştığı bir sektör.
İşimiz görünürde kolaylaşıyor; çünkü bütün yazılımların karşılaştığı ortak problemler açık kaynak toplulukları ve şirketler tarafından çözülüyor ve ortalama yazılımcıların bu problemleri bir daha çözmelerine gerek kalmıyor. Evet, teoride işimizi kolaylaştırıyor fakat pratikte bizi Demokles’in kılıcının altında, hiç durmadan bir şeyler öğrenmek zorunluluğunda bırakıyor.
Şöyle ki, iki sene önce başlayıp kenara koyduğumuz bir projeye şimdi devam etmek istediğimizde, kodumuzun çağ dışı kaldığını, “çöp” olduğunu görürüz. 20 yıl önce çözülmüş, standartlaşmış, login, şifremi unuttum gibi basit akışları yapabilmek için bile her şeye sıfırdan başlamak zorunda kalabiliyoruz.
Örneğin ön yüz geliştiricileri, çok basit HTML, Javascript, CSS ile sayfayı çıkartabilecekken, kendini React-Angular çekişmesinin içinde buluyor, CSS’in yalnız başına kullanılmadığını, SASS ile yer değiştirdiğini görüyor. Çıplak Javascipt kullanmak; Ecmascript’e, TypeScript’e geçmemek dinozorluk olarak görülüyor. Birdenbire, TypeScript’i Javascript’e çeviren araçlar çıkıyor ve siz daha buna ne kadar ihtiyacınız olduğunu tartışamadan, hangi çevirici aracın daha iyi olduğunu tartışırken buluyorsunuz kendinizi.
Aynı sıkıntılar backend yazılımcıları için de geçerli oluyor. JSF’in moda olduğu günlerden JSF’in eski kafalılık olduğu günlere birkaç sene içerisinde geliyoruz.
Karmaşıklaşan eski problemler
Bu hızlı değişimin “mühendislik açısından” sebebi, problemlerin gittikçe karmaşıklaşması… Gayet sıradanlaşmış ihtiyaçlar zamanla karmaşıklaşıp mimari, tasarımsal problemlere ve ortalama yazılımcıların çözmekten imtina edeceği sorunlara dönüşebiliyor. Bu problemlere birkaç örnek vereyim:
- Loginde CSRF ataklarının artık asla görmezden gelinmemesi gerekliliği ve şifrelerin Bcrypt gibi sağlam algoritmalarla şifrelenmesi gerekliliği
- Sunucu tarafındaki uygulamaların, kullanıcı sayısı arttığında hemen yatay ölçeklenebilir olması, yani aynı uygulamanın birden fazla makineye kurulduğunda sistemin kapasitesinin kolayca arttırılabilmesi
- Sistemin farklı parçalarının, kullanım yoğunluğuna göre kolayca büyültülüp küçültülebilmesi
- Sistemin, verisini kolayca API olarak sunabilmesi ve diğer API’ları kullanabilmesi
Ortalama yazılımcıların çözmekten hoşlanmayacağı, belki de çözemeyeceği bu problemlere çözümler idealist açık kaynak gruplarından ya da şirketlerden geliyor. Bunun için ne kadar minnettar olsak azdır. Fakat, işin bir de öbür yüzü var. Şirketlerin, sektörü domine etme, standart belirleme savaşı…
Standart belirleme savaşı
Facebook, Google, Oracle, VMWare gibi şirketler karmaşıklaşan problemler için frameworkler ve kütüphaneler yayınlıyorlar. Kendi iç projelerinin ihtiyaçlarını karşılayacak şekilde hazırladıkları kütüphanelerin sektör tarafından benimsenmesi için PR çalışmalarına başlıyorlar. Buna, hem ticari itibar açısından hem de mühendislik itibarı açısından ihtiyaçları var.
Örneğin Google, Angular’ı alıp ikinci versiyonunda bambaşka bir şeye dönüştürdüğünde, TypeScript’i kabul ettiğinde hem Facebook’un React’ına tekrar rakip olmak istiyor, hem tek sayfalık web ve mobil uygulamalarını standart hale getirmek istiyor. Çünkü standart belirlemek bir şirket için son derece büyük bir itibar kaynağı. Diğer küçük yazılım şirketleri için de Google ile aynı teknolojiyi kullanmak da bir itibar olayı zaten…
Adobe’un Flash’ı senelerce, Microsoft’un Silverlight’ı piyasada yer edinemesin, HTML 5 standart olamasın diye zararına yaşattığını biliyoruz mesela. Bunlar gayet normal.
Büyük şirketlerin bu itibar ve ticaret savaşında olan biz ortalama yazılımcılara oluyor. Ortalama yazılımcı derken tek yaptığı, frameworkleri ve kütüphaneleri, verilen iş çözümleri için kullanmak olan yazılımcılardan bahsediyorum.
Şirketlerin ve yazılımcıların adaptasyonu
Şirketlerin yazılım mimarları ve yöneticileri, geliştirilen kütüphaneleri bir an evvel yazılımlarına dahil etmek istiyor.
Çünkü daha yeni teknolojiyi kullanan şirkete daha meraklı, daha yenilikçi özetle daha sofistike yazılımcılar geliyor. İyi yazılımcıların, eski teknolojilerde sıkışmış kalmış şirketlerden kaçtığı bir gerçek.
Bu sebeple, daha pahalı olmak, daha “teknoloji odaklı” şirketlerde çalışmak isteyen ortalama yazılımcılar, daha yeni teknolojileri ve dilleri öğrenmek/uygulamak peşine düşüyor.
Bir full-stack yazılımcının öğrenmesi gereken çok sayıda framework var. Örneğin Spring Boot, Spring Security, Spring Data, MongoDB gibi temel bir sepet; Oracle, JSF, Primefaces sepetinden gelen bir yazılımcı için gayet zorlu bir sınavdır. Her an MEAN sepetinin (stack yerine sepet diyorum) ticari başarı kazanması ihtimaline karşı bunu da öğrenmesi gerektiğini unutmamak gerekir. Bir teknolojiyi öğrenmenin ortalama yazılımcıya bedelinin aylar olduğunu düşünürsek, bir sepeti öğrenmek 5–6 ay sürer diyebiliriz.
Bu durumda ortalama bir yazılımcı, hangi sepetin standart olacağını kestiremeyip hepsini öğrenme yoluna gider ve bir iki senesini yeni sepetleri öğrenmeye harcar ya da zamandan tasarruf etmek için hepsini yarım yamalak öğrenir geçer.
Çalışacağı proje için bu sepetlerden biri seçildiğinde konu hakkında yeterince bilgi sahibi olur. Bir projede ya da şirkette ortalama 1.5–2 sene durduğumuzu varsayarsak, biz bu proje üzerinde çalışırken, sektörde başka bir sepet ticari başarıya ulaşmış ve biz iş değiştirme vakti geldiğinde çoktan “modası geçmiş yazılımcı” sıfatına nail olmuş olabiliriz.
Teknoloji savunuculuğu
Her yeni projeye başlanırken, yazılımcıların ve yazılım mimarlarının, teknoloji seçme kavgasına şahit oluruz. Kimse kendisine “modası geçmiş” dedirtmek istemediği için, projede kullanılması için bildiği sepeti ölümüne savunmaya başlar. Çünkü yenilgiyi kabul etmek demek, yeni bir öğrenme sürecine girmek zorunda kalmak demektir. Bu sürekli öğrenme süreci, 10 yıllık bir yazılımcı için çoktan kabak tadı vermiştir.
- Abi X mi kaldı ya!
- Başkan, hangi yüzyılda yaşıyoruz, ne RDBMSi Allah’ını seversen
- Hacıt, köylü müsün, APIyi kendimiz mi yazacağız, Swagger var ya!
Herkes, kendi geldiği sepetin artılarını anlatır, eksilerini görmezden gelir ve bir fikir birliğine varılamazsa, o an için sektörde en yaygın kullanılan ne ise onunla devam edilir. Fakat yine de açılan komikli eleman ilanlarına, tartışmada geçen teknolojilerin isimleri de sıkıştırılır. Ne olur ne olmaz. İş ilanlarında gördüğünüz bir sürü kısaltma ve teknoloji ismi bu kafa karışıklığının bir sonucu oluyor genellikle.
Uygulanacak olsa da olmasa da zamanının “en hit” teknolojileri ilanlarda kullanılır. Ancak bir kısmı da hayata geçirilebilir.
Genç ve dinamik yazılımcılar, CV’sinde güzel duracağı için ya da teoride bildiklerini pratikte uygulamak için her fırsatta, gerekli ya da gereksiz olduğuna bakmadan, yeni teknolojiyi kullanmak için bastırır. İşte burada sıkıntı başlıyor. Çünkü,
Her teknoloji, kendi best-practice’leri ile tasarım şablonları (design patternları) ile tehlikeleri (pitfall) ile gelir. Henüz olgunlaşmamış teknolojiler kendi içerisinde de sıkıntılar yaşayıp mimari değişikliklere gidebilirken, bunları kullanan yazılımcıların bu değişikliklerden haberdar olması, görünmez tehlikeleri deneyimlemesi, önlem alabilmesi gereklidir.
Mesela çok proje, Hibernate’in N+1 problemleri, ikinci seviye önbellek yapıları yüzünden aylarca uzamış ya da çöpe gitmiştir.
Transaction yönetme işini manuel mi yapalım, Spring’e mi bırakalım, sunucuya mı bırakalım sorusu bile, projenin ikinci senesinde cevap bulmuş olabilir mesela.
Her şey mükemmel gitse bile, teknoloji sepetiniz iki sene sonra çöpe dönüşmüş olabilir. Mesela, Angular 1 ile yazılmış projelerin çöp olduğundan bahsedebiliriz şu an için. NodeJS’in artık eskisi kadar popüler olmadığını Go’nun artık zorlama olduğunu görüyoruz. Kotlin’in nereye kadar varolabileceğini kestiremiyoruz.
Teknoloji sepetiniz çöpe gitmeye başladıysa işte o noktada ticari kaygılar başlıyor. X teknolojisi ile yazılmış yerleri Y ile yeniden yazma işi başlıyor. Tabi yazılımın farklı parçalarında da aynı değişim oluyor. Bunların arasındaki mentalite değişiklikleri uyumsuzluklara yol açarken projenin masrafı gereksiz yere artıyor, çalışan sistem bozulmaya başlıyor, çok şey kötüye gidiyor.
Canavar gibi çalışan sistem içerisinde, sektörün dayattığı sepetlere geçiş yapılmaya çalışılıyor. Ve inanın, bu, iki-üç senede bir tekrarlanan bir durum.
Şirketlerin muhafazakarlaşması
Bu noktada, şirketler, her gelen teknolojiye atlamamayı seçiyor ve gelişmeleri geriden takip etmeye başlıyorlar. Projelere eski stackler ile devam etme kararı alıyorlar. Bu yüzden ortalama üstündeki yazılımcılara cazip gelemiyorlar.
Çünkü ortalama üstündeki yazılımcılar, CV’lerinde, büyük kullanıcılarla, büyük problemlerle uğraşmış, en yeni teknolojilerle çalışan sistemlerin olmasını istiyorlar.
Değişim maliyetlerini karşılayamayacak şirketler, eski teknolojilerle devam ederken, daha az maaş verdiklerini de görünce mutlu oluyorlar. Çünkü, eski teknoloji bilen yazılımcı, ucuzlamış yazılımcı demek sektörde.
Bunu fark eden ortalama yazılımcılar da, fiyatlarının düşmesini engellemek için yeni teknolojileri öğrenmek zorunda hissediyor kendini. İşte aşağıdaki şakanın temeli bu.
Kısaca, bazen problemler gerçekten karmaşıklaşıp yeni çözümlere ihtiyaç duysa da, çoğu zaman, basit problemler karmaşıkmış gibi gösterilerek, ticari kaygılarla “yeni teknolojiler” uyduruluyor ve gelir kaybına uğramak istemeyen yazılımcılar bu sarmala dahil olmak zorunda kalıyor ya da üst gelir kesiminde yer alabilmek, ucuzlamamak için “teknoloji uydurma” işini körüklüyor.
Normalde büyük bir keyif olması gereken öğrenme işi yavaş yavaş bir angaryaya, aynı şeyleri farklı şekillerde, tekrar tekrar, en baştan yapmaya dönüşüyor. Bu da yazılımcıları mutsuz ediyor.
