Teknoloji ile Büyümek

Son yıllarda çok duyduğumuz “inşaat sektörü ile büyümenin sanal olması aslında ülkeye hiçbir katma değer katmaması” konusu ile yazılım ekiplerinin teknoloji-ile-büyüme merakı arasında bir bağlantı kurmaya çalışacağım.

İlk Pragmatic Programmer’ı [1] okuduğum günden beri şu örneği hatırlarım: “Yazılımcılık bahçivanlığa benzer, ne kadar ekersen o kadar bakım yapmak zorunda kalırsın” gibi birşeydi. Yazılım ekipleri etraflarında sürekli olarak değişen teknolojilere adapte olmaya çalışırken ve sistemlerini büyütürken kendi teknolojilerini geliştirme fırsatlarını kaçırıyor olabilirler mi? Bazen bana gelen “neden VeryCoolTechnology 14.45.4'a geçmiyorsunuz?” sorularına “çünkü biz de bir teknoloji geliştirmeye çalışıyoruz” şeklinde cevaplar verir oldum. Belki de şunu kabul etmeliyiz:

Teknoloji üretmek istiyorsan, kullandığın teknolojileri azaltmalısın.

Öz’ün Peşinde

Biraz uç olmakla birlikte bu duruma en güzel örneği akademiden vermek isterim. Yeni bir algoritma üzerinde çalışan bir araştırmacı/akademisen o kodu mümkün olduğunca saf bir ortamda yazmaya çalışır. Onun için tek gerekli olan bir iki veri yapısı ve if bloğudur. Üzerinde çalıştığınız şey eğer daha önce bulunmuş şeylerin varyant bir uygulaması değilse öz bu kadar basittir. Tek ihtiyacınız konsantrasyon, zaman, bir programlama dili ve deneme-yanılmadır [2]. If bloğunu’u Python’la ya da Java ile yazmanızın bir önemi yoktur. Hangi Serializer’ı kullandığınızın da anlamı yoktur, hatta IDE’niniz bile. O durumda en iyi dil en iyi bildiği dildir araştırmacının. Araştırmacı özgün bir problem tanımlamaya çalışıyor ya da özgün olmayan bir probleme özgün bir çözüm bulmanın peşinde giden kişidir. Problemi çözdüğünde onun işi bitecektir. Bir 10 yıl sonra onun makalesini okuyan mühendisler o formülleri kullanarak koca koca sistemleri zaten uygulayacaklar. Google[3], Hadoop[4], MapReduce[5], hemen hepsi sadece on sayfada ifade edilebilecek makalelerdi. Örneğin Google MapReduce makalesini yayınladı, ertesi yıl koskoca Hadoop ekosistemi kuruldu. Ekosistem inşaat sektörüne benzer. Koca koca iş makineleri milyonlarca dolar harcar, hepsi zaten olan bir öz’ü tüm dünyaya uygulamak içindir. O ekosistemde IDE’ler kamyona, bileşenler tuğlaya, yazılımcılar ustabaşılarına benzerler…

Araştırmacının peşinde olduğu şey ise sadece öz’dür. Öz’ün peşinde koşarken saniyede-milyon-kullanıcı-talebini-karşılamak gibi rutin mühendislik problemleri çözmek zorunda değilsinizdir (çoğunlukla). Production’dan sorumlu araştırmacı pek görmezsiniz.

Prangalar

Yazılım ekipleri konusuna dönersek; paket yönetim araçları gelişti diye 3. parti bileşen kullanımının maliyeti sıfırlanmadı. Koca koca yazılımcılar 11 satırlık bir left-pad() fonksiyonu için bile dışarı referans vermek gibi bir tembelliğe alışmaya başladılar [6]. Bilinçli bir planlama ile yapılmadığında teknolojik bağımlılıklar kolaylıkla prangalara dönüşebilir. Aslında gerçek anlamıyla her bağımlılık-okunu sisteminize bir pranga gibi hayal etmelisiniz. O oklar arttıkça kodunuzu daha zor derleyecek, uyum sorunları yaşayacak, yeni araçlar kurmadan devam edemez hale geleceksiniz. Bilenler için burada teknoloji bağımlılıklarını Eric Evans’ın D.D.D. kitabında [7] bahsettiği “domain’i teknolojiden ayırma” bağlamındaki gibi kullanıyorum. İyi yazılım mühendisliği yapmak artık nerede ne zaman doğru bağımlılığı sisteme tanıtacağına karar vermeye dönüştü. Bir yandan da bütün yazılımcılar övünerek virgüllerle ayırarak bağımlılık listeleri sıralıyorlar: Redis,React,Vue,Spark,Kubernetes. İş ilanları teknoloji listesine, blog yazıları “biz nasıl .Net Core’a geçtik” loglarına dönmeye başladı. MantiSoyle.com’un Kubernetes ile seamlessly-container-orchestration yapmasına gerçekten gerek oluyor mu yoksa cv’ye bir virgül daha eklemek mi oluyor esas amaç…

Referanslar

[1] Hunt A. The pragmatic programmer. Pearson Education; 1999.
[2] Sezgisel Faaliyetten Bilimsel Faaliyete Geçiş…
[3] Brin S, Page L. The anatomy of a large-scale hypertextual Web search engine* 1. Computer networks and ISDN systems. 1998.
[4] Shvachko K, Kuang H, Radia S, Chansler R. The hadoop distributed file system. InMSST 2010 May 3 (Vol. 10, pp. 1–10).
[5] Dean J, Ghemawat S. MapReduce: simplified data processing on large clusters. Communications of the ACM. 2008 Jan 1;51(1):107–13.
[6] How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript
[7] Evans E. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional; 2004.