Yazılım endüstrisi inanılmaz büyük, dağınık, neredeyse her endüstrinin içerisine kendisini anahtar bir oyuncu olarak yerleştirmiş bir endüstri. 2011 yılında A16Z'nin kurucularından Marc Andreessen "Why Software Is Eating The World" (Yazılım Dünyayı Neden Ele Geçiriyor) yazısında sırtını yazılıma dayayan Amazon, Netflix, Spotify gibi devlerin nasıl ortaya çıktığını ve büyüdüğünü benim anlatabileceğimden çok daha iyi anlatıyor. Bugün benzer bir soruyu "Yapay Zeka Yazılımı Ele Geçirecek Mi?" ekseninde soruyoruz, yazılım endüstrisine ne olacak, sektördeki işler nasıl değişecek, 2030'da hala kod yazıyor olacak mıyız onu anlamaya çalışıyoruz, ancak bu tartışmaların altında yatan ekonomik dengeleri yeterince iyi anladığımızı düşünmüyorum. Bu sebeple oturup biraz sektörün ekonomisi nasıl işliyor, kim kime, niye para veriyor bunu araştırmak, araştırırken de yazmak istedim. Özellikle işlerimize ne olacak, bilgisayar mühendisliği yazdığıma pişman olmalı mıyım diyen öğrenci arkadaşlara faydası olmasını hedefledim. En azından ben bölümü okurken okusam faydası olacak şekilde yazmaya çabaladım.

Konuyu birkaç eksende ele alacağım:

• Endüstriyi Resmetmek
• Omurga Yazılımlar
• Açık Kaynak
• Maaşlar
• Yapay Zeka

Endüstriyi Resmetmek

Girişte bahsettiğim gibi yazılım endüstrisi büyük ve dağınık, detaylı sektörel analizler yüzlerce farklı alanda binlerce şirketi farklı segmentlere ayırıp onların sektördeki pozisyonlarını inceliyor. Ben çok daha basit bir harita çizmeye çalışacağım.

Endüstriyi önce 2 temel parçaya bölelim, ön-yüzü (buraya tüketici yazılımları diyeceğim), ve arka yüzü (buraya da omurga yazılımlar diyeceğim). Tüketici yazılımları bizlerin günlük hayatta karşılaştığı yazılım ürünleri. Bu ürünler bizim gündelik problemlerimize, ihtiyaçlarımıza, isteklerimize dijital çözümler üretiyor, bir noktada ben bu ürünleri bir çeşit "dijital dönüşüm" olarak görüyorum. Word, Google Docs gibi editörlerin daktilonun yerini alması, Wikipedia'nın geleneksel ansiklopedilerin geniş, çeşitli, elimizin altında anlık erişilebilir dijital bir hali olması, sosyal medyanın mahalle meydanlarındaki, kahvelerdeki, günlerdeki konuşmaları dijital ortama taşıması, Netflix, Spotify gibi platformların sinemalar, tiyatrolar, konserler gibi eğlence mekanlarının alternatifi olarak görev görmesi, öğrencilerin ChatGPT'yi özel ders hocası gibi kullanması... Bu uygulamaların neredeyse hepsi bizlerin günlük tecrübelerimizi dijital ortamda yeniden oluşturma, yazılım ürünlerinin ekonomik dinamikleri sayesinde çok daha ucuz fiyatlara "benzer" tecrübeler sunma peşinde. Bu uygulamalar için yazılım, ya da kod, aslında bir araç, bir amaç değil. Nitekim Netflix benzer hızda benzer tecrübeyi daha ucuza CD'leri kargolayarak evimize kargolayarak sunmaya devam edebiliyor olsaydı, dünyanın en büyük veri merkezlerini kurmak için uğraşmazdı.

E peki tüketici yazılımları için yazılım bir amaç değil de araçsa, yazılımın hangi özellikleri onu alternatif çözümlere göre ekonomik olarak daha makul kılıyor?

Netflix'i düzenli örneğimiz olarak elde tutalım. Bir tarafa kullanıcıların fiziksel bir katalogdan film seçip, telefonla Netflix'i arayıp, İş bankasını arayınca karşınıza çıkan robotun yerine sizi bir müşteri temsilcisi müsait olana kadar bekleten, müşteri temsilcisine istediğiniz filmi söyledikten sonra onun o filmin CD'sini kargolatıp size 2 gün sonra gönderdiği bir dünya düşünelim. Diğer tarafta da hepimizin bildiği, sevdiği, çaktırmadığımızı düşünerek arkadaşlarımızla kurduğumuz aile grubundan 1 dakika içerisinde binlerce film ya da diziden birisini seçip izlemeye başlayabildiğimiz Netflix'i.

Aslında baktığınızda bu ürünler birbirinin direkt karşılığı değil, güncel Netflix hayal ettiğimiz geçmiş Netflix'ten üstün değil. Bir CD aldığınızda artık ona sahip oluyorsunuz, pratikte o CD'yi arkadaşlarınızla paylaşabilirsiniz, hatta belki kopyalayıp satmaya bile çalışabilirsiniz, CD artık sizin mülkünüz. Günümüzdeki video/müzik yayın platformları sahipliği ortadan kaldırarak abonelik bazlı bir sistemle bizleri aydan aya hangi ürünlerin içinde olduğunu bile bilmediğimiz bir ürün kümesine erişim ile sınırlandırıyor, kendilerini ekonomik olarak karlı hale getirdikleri iş modeli bu çünkü, yani teknoloji tek başına bir süreci iyileştirmeye yetmiyor, dijital olarak yeniden hayal ettiğiniz tecrübelerin iş ve gelir modellerini tasarlamanız, bu aşamada bu tecrübelerin bazı eksenlerini kötüleştirebileceğinizi kabul ettmeniz gerekiyor.

Benzer bir analizi pek çok tüketici yazılımında görebiliyoruz, mesela yazılımlaştırılmış süreçler geleneksel alternatiflerine göre çok daha az esnek olabiliyor, nüfus müdürlüğündeki çalışanın sizin için yapabileceği değişiklikleri E-Devlet'te yapamayabiliyorsunuz. ChatGPT herhangi bir özel ders hocasından çok daha ucuza çok daha fazla bilgi sağlayabiliyor size, ancak o bilgilerin doğru olduğuna dair bir kesinlik sunmuyor, hatta çoğu zaman sizin yanlış ön yargılarınızı beslemeye devam ediyor. Linkedin sizi fiziksel olarak karşılaşamayacağınız pek çok kişiyle "bağlıyor", ancak bir konferasnta yüz yüze görüşüp el sıkışmanın, muhabbet etmenin yerini alamıyor.

Ancak yazılım ürünleri, geleneksel alternatiflerine göre çok daha ucuz, hızlı, ve sürekli. Netflix size fiziksel CD'ler göndermeyerek hem her CD'nin materyal maliyetinden, hem de o CD'yi üretip size göndermesi gereken lojistik ihtiyacından kurtuluyor, teknoloji sayesinde anlık hizmet sunabiliyor. Bunun yanında sizden düzenli geri dönüt alabiliyor, A/B Test gibi geleneksel hizmetlerde mümkün olmayan ürün ve süreç optimizasyonları uygulayabiliyor, kullandığınız uygulamayı, o uygulamayı destekleyen sistemi her gün geliştirebiliyor.

Buraya kadar görece makro tüketim yazılımlarından bahsettim, Netflix gibi, Wikipedia gibi hayatımızın her yerine girmiş, neredeyse her demografiğe hitap eden yazılımlardan. Tüketim yazılımlarını bir spektrum olarak ele alırsak bir de diğer uçtaki mikro tüketim yazılımları var, çok daha küçük demografiklerin spesifik ihtiyaçlarına cevap vermek üzerine kurulu yazılımlar. Kilo vermek isteyenler için diyet uygulamalarından yeni anneler için tavsiye uygulamalarına, fotoğraf filtreleme ve işlemeye, Forest gibi odaklı çalışma uygulamalarına, alıcısı olan her alanda uygulamalar var. Tüketim yazılımlarını sadece bilgisayar ya da telefonda kullandığımız web ya da mobil uygulamalar gibi düşünmek de doğru değil, evimizdeki otomatik ışıktan buzdolabımızın sıcaklığını ayarlayan gömülü sistemlere kullandığımız fiziksel elektronik sistemleri güçlendiren programlar da aslında tüketim yazılımları.

Peki bu ayrımların bize faydası ne?

Temelde varmak istediğim nokta şu, tüketim yazılımlarında ana uzmanlık ve odak aslında programlama ya da yazılım değil. Diyet uygulamasında diyetisyenin, fotoğraf uygulamasında fotoğrafçının hedef kitlemize nasıl bir çözüm sunmalıyız sorusuna verdiği cevabın dijital var oluşunun bir gereksinimi yazılım, bu uygulamaların çözdüğü problemlerin yazılımın ucuz, hızlı, sürekli olma özellikleriyle daha geniş bir kitleye daha karlı bir şekilde sunulmasına izin veren mekanizma yazılım. Bu tarz bir uygulamanın yazılmasında ana işler (1) yazılımın hangi özelliklere sahip olacağına karar vermek, (2) bu özelliklerin tamamını içerebilecek bir alan modellemesi (domain modeling) yapmak. İşin yazılımsal zorluluğu alanın ne kadar zor modellenebildiğine göre değişiyor. Bazı alanlar o kadar fazla kez modellendi ki, teknolojiye biraz yatkınlığı olan birisi neredeyse 15 senedir Wordpress kullanarak programlamayla hiçbir ilgisi olmadan e-ticaret sitesi açabiliyor kendi ürünlerini satmak için, ya da Bubble/Wix gibi no-code/low-code platformları kullanarak bir web platformu oluşturabiliyor insanlara belli hizmetleri sunan.

Diğer yanda bazı alanları modellemek doktora seviyesinde araştırmacıların uzmanlıklarını gerektirebiliyor. Örnek olarak fizik simülasyonları inşaat ve mimarlıkta, otomotiv sektöründe, savunma sanayiinde kullanılıyor, kullanılan materyallerin fiziksel özelliklerini modellemek ayrı bir iş, bu modellemelerin insanların kullanabileceği seviyede performanslı olmasını sağlamak ayrı bir iş, bu modellerin doğrulanmasını yapmak ayrı bir iş. Sosyal sistemleri modelleyen yazılımlar için de dünyanın sürekli değiştiğinin farkında olarak modelleme yapmak ayrı bir zorluk. Ülkelerle ilgili verileri işlediğiniz bir sistem düşünün, bir ülkenin adının değişebileceğini (Turkey -> Türkiye), bir ülkenin ortadan kaybolabileceğini (Yugoslavya, SSCB) ve bunun sonucunda ortaya yeni ülkeler çıkabileceğini, ülkenin farklı veri tabanlarında farklı adlara sahip olabileceğini hesaba katmak zorundasınız. Latin alfabesinin sizin hayal ettiğiniz kadar basit ya da yaygın olmadığını fark edip buna göre sisteminizi daha geniş bir yelpazede tasarlamanız gerektiğini düşünmeniz gerekiyor. Tabii ki bu kompleks alan modellemelerinin de ayrı performans ve karmaşıklık maliyetleri var, dolayısıyla bunları da hesaba katmanız gerek.

Modellediğimiz alanın karmaşıklığını bir kenara bıraktığımızda, daha çok makro uygulamalarda karşımıza çıkan ölçek problemiyle karşılaşıyoruz. 300 kişinin kullandığı bir uygulama ile 300.000 kişinin kullandığı, 30.000.000 kişinin kullandığı uygulamalar çok temel düzeylerde birbirinden farklı. Her şeyden önce uygulamanın kitlesi büyüdükçe bahsettiğim modelleme problemleriyle karşılaşma ihtimaliniz artıyor. Belki ilk 1 milyon kullanıcınızda Kiril alfabesi kullanan kimse ile karşılaşmamış olabilirsiniz, ancak kullanıcı ölçeği büyüdükçe daha çeşitli arka planlardan insanlarla karşılaşacaksınız. Farklı diller konuşacaklar, farklı alfabeler, işletim sistemleri, zaman dilimleri, ödeme entegrasyonları, cihaz boyutları, internet hızları kullanacaklar. Bu çeşitlilik sizin modelleme ihtiyaçlarınızı kat be kat arttıracak. İkinci tip bir kompleksite ise uygulamanız sağladığı özellikler anlamında büyüdükçe yazılımınız da büyüyecek. Bugün ortalama bir yazılım ürününün arkasındaki sistemin birkaç yüz bin satır kodu olması hiç şaşırtıcı değil. Bu büyüklük size karmaşıklık olarak geri dönüyor, yeni bir özellik eklemek istediğinizde onu eklemeniz zorlaşıyor, uygulamada bir hata keşfettiğinizde onun sebebini tespit etmek saatler, günler sürebiliyor, özellikle de yazılımınızın mimari dizaynı bu büyüklüğü hesaba katacak şekilde yapılmadıysa. Üçüncü tip kompleksite ise kullandığımız cihazların fiziksel limitlerini algoritmik çözümlerle aşma çabasından geliyor. Mesela bilgisayarlarımızda 2 tip hafıza olduğunu düşünelim, geçici ve hızlı RAM, kalıcı ve yavaş disk. Eğer ki kullanıcı RAM'e sığmayan bir dosyayı yüklemek isterse ne yapmalıyız? Benzer şekilde, bir web uygulaması yazdığımızı varsayalım, bu web uygulamasını kullanıcılara sunmamızı sağlayan bir sunucu uygulamamız (application backend) var. Bu sunucunun fiziksel kapasitesi saniyede 100 kullanıcıya cevap vermesine izin veriyor ise, saniyede 120 kullanıcı aldığımızda ne olacak? Ya kullanıcıların bir kısmını düşüreceğiz, mesela sınav sonuçları açıklandığı gün ÖSYM sitesine giremediğinizde ÖSYM sizin isteklerinizi düşürüyordu... Diğer bir ihtimalde ise kodumuzu daha fazla kullanıcıya aynı hizmet verebilmesi için optimize edebiliriz, daha güçlü ve pahalı bir makineye geçebiliriz, ya da pek çok makineyi aynı anda kullandığımız dağıtık bir sistem kurgulayabiliriz.

Burada en başta bahsettiğim bir soruya geri döneyim, kim kime neden yazılım ürünü geliştirmesi için maaş ödüyor?

Yazılımcının en temel işi alan uzmanlarının ortaya koyduğu gereksinimleri sağlayacak bir yazılım ürünü oluşturmak. Bu gereksinimler bir uygulamanın nasıl gözükmesi gerektiğinden kullanıcının aldığı aksiyonların uygulamada nasıl bir akışa yol açtığına, aynı anda desteklenmesi beklenen kullanıcı sayısına, kullanıcının bir aksiyonu sonucunda aldığı cevabın kaç saniyeyle limitli olduğuna... çok farklı şekiller alabilir. Tabii ki bu kararlar bir vakumda değil, bir yandan da kısıtlı kaynakların olduğu finansal bir denklemde alınıyor.

Mühendislik de, en temelde kısıtlı kaynakların matematiksel modellemeler sonucu optimizasyonu aslında. Yazılım ya da bilgisayar mühendisliğinin objesi ise önceki paragraflarda bahsettiğim süreçleri optimize etmek. Bu optimizasyon projenin ilerlemesini hızlandıracak kararlar sonucunda projenin alacağı toplam insan saatini azaltmak da olabilir, projedeki fiziksel kaynaklara yapılan harcamalar ile algoritmik geliştirmelerin ya da dağıtık sistem tasarımlarının arasındaki dengenin kurulması da olabilir, projede kullanılacak olan dış kaynaklara ve hizmetlere karar verilmesi de olabilir.

Ürün sahipleri bu kararları alabilecek, bu kararların sonuçlarının sorumluluğunu alabilecek mühendislik ve takım liderlerine, bu gereksinimlere uyabilecek uygulamalar geliştirebilen yazılım mühendislerine maaş ödüyor. Bir uygulamanın bir saatliğine kapalı kalmasının şirkete bir maliyeti var. Bir isteğin saniyenin 100 milisaniye daha uzun sürmesinin şirkete bir maliyeti var. Bir uygulamada kullanıcıyı etkileyen hatalar olmasının şirkete bir maliyeti var. Dolayısıyla yazılım mühendisinin daha hızlı, dayanıklı, okunabilir, anlaşılabilir, büyütülebilir, güvenli yazılımlar geliştirebiliyor olmasının şirkete direkt olarak finansal faydaları var, bu faydalar yazılım endüstrinin var olmasını ve büyümesini sağlıyor.

Uzuuunca bir şekilde tüketici yazılımlarından, bu yazılımların nasıl ihtiyaçları neden çözdüğünden, yazılım mühendislerinin bu yazılımları geliştirmedeki rollerinden bahsettik. Peki bu ürünlerin tüm parçalarını şirketler sıfırdan mı geliştiriyor? Tabii ki hayır. Nasıl araba şirketleri yeri geldiğinde basit parçaları, yeri geldiğinde ise motor gibi kritik bileşenleri güvendikleri üçüncü parti şirketlerden alıyorsa, yazılımda da benzer mekanizmalar var, bunlardan iki paragraf önce dış kaynaklar ve hizmetler olarak kısaca bahsetmiştim, şimdi omurga yazılımlar adı altında bu dış kaynak ve hizmetlerin ekonomik mekanizmalarını inceleyeceğim.

Omurga Yazılımlar

Not: omurga kullanmak istediğim asıl terim için --"backbone"-- çok iyi bir çeviri değil, daha iyi bir çeviriniz varsa iletirseniz sevinirim.

Bahsettiğim optimizasyon problemlerini, ölçekle ortaya çıkan karmaşıklığı okuduğunuzda bilgisayar mühendisliği yazdığınıza pişman olmuş, acaba başka bir mühendislik mi yazsaydım daha mı kolay olurdu diye düşünmüş olabilirsiniz, ancak şimdi sizi biraz daha endüstrinin realitesiyle tanıştıracağım, ve aslında yaptığımız işin çok büyük bir kısmının mühendislik olmadığını göreceksiniz, çünkü kullandığımız makineler çok ucuz, "compute is cheap". Geçtiğimiz 70 senede yazılım endüstrisi donanım endüstrisinin üssel gelişiminden fazlasıyla yararlandı, ortalama her 18 ayda bir kullandığımız makineler iki kat daha güçlü hale geldi (Moore Yasası). Bugün cebimizdeki telefonun Apollo 11'den 100.000 kat daha fazla hesaplama gücü, 7 milyon kat daha fazla hafızası var, ve biz onunla 2048 oynuyoruz. Tabii ki şaka bir yana, günümüz bilgisayarları ekrana harfleri gözümüze güzel gelen bir şekilde çizmek için Apollo'nun çalıştırdığı fizik simülasyonlarından daha karmaşık hesaplamalar yapıyor, ortalama bir sosyal medya uygulaması 1970 yılındaki tüm veriden daha fazla veriyi tek bir günde telefonumuzda işliyor, dinlediğimiz bir müzik klibi 1990'lardaki 100 albüme eşdeğer miktarda veri saklıyor. Cihazlarımızda çok daha fazla veri tutuyor, çok daha fazla veri işliyoruz, bunları çok daha kompleks algoritmalarla ve protokollerle yapıyoruz; eğer ortalama bir yazılım mühendisi yazdığı uygulamanın tam anlamıyla ne yaptığını öğrenmeye kalkarsa bunun için birkaç yılını sadece okuyarak ve araştırarak harcaması gerekebilir. Dolayısıyla nasıl Aston-Martin motorları için Mercedes'e güveniyorsa, yazılım firmaları da kritik, bugün kurduğumuz sistemlerin omurgası haline gelmiş pek çok kendini kanıtlamış, hazır yazılım ürününü kullanıyor.

Omurga yazılımların bize verdiği garantileri kullanarak, hesaplama gücünün ucuzluğuyla da birlikte yazılım ürünlerini özellikle ilk aşamalarda minimal mühendislik yüküyle geliştirebiliyoruz. Alan modellemelerini basit tutarak geliştirilen yazılımın karmaşıklığını sınırlayabiliyor, ortalama tek bir makine ile saniyede binlerce isteği karşılayarak dağıtık sistemlerin ve optimizasyonun yükünden kurtulabiliyoruz, klasik bir yazılım ürününün ihtiyaç duyduğu veri tabanı(SQLite, PostgreSQL, MongoDB, Firebase), kuyruk (Kafka, RabbitMQ, SQS), önbellek (Redis, Memcached), yük dengeleyici (NGINX, HAProxy), konteyner (Docker, Kubernetes), izleyici (Prometheus, Grafana), nesne deposu (S3, R2), içerik dağıtım ağı (Cloudflare, Akamai) gibi pek çok ihtiyacı çoğunluğu açık kaynak, yüksek yük altında kendini kanıtlamış, matematiksel modellerle desteklenmiş, çeşitli hata senaryolarına karşı dirençli omurga yazılımlar ile yazılım geliştirme sürecini hızlandırabiliyoruz.

Yalnızca yüksek yükü karşılaşayabilmek ya da optimizasyon için kullanmıyoruz tabii ki dışarıdan yazılımları. Programlama dilleri çoğu zaman yüz binlerce kütüphanenin olduğu büyük ekosistemlerden oluşuyorlar. Bu ekosistemler bize bir web sitesi oluştururken kullanabileceğimiz Django gibi tam paket (batteries-included) çözümler de sunuyor, yetkilendirme (authorization), kimlik doğrulama (authentication) gibi bir uygulama oluşturmak için temel faydalı paketler de sağlıyor, aviyonikten robotiğe, yapay zekaya, burada say say bitiremeyeceğim çok farklı alanlarda kullanabileceğimiz, bahsettiğimiz algoritmik problemleri, alan modellemelerini çözen, bize hazır çözümler sunan kütüphaneler var. Sırtımızı bu koskoca ekosisteme taşıyarak son tüketim uygulamasını neredeyse sadece ekosistemden paketleri birbirine bağlayarak oluşturabiliyoruz çoğu zaman, en azından küçük ölçeklerde, basit modellerle.

Ancak birilerinin de bu omurga yazılımları yazması gerekiyor, bu yazılımlar kendileri bir anda ortaya çıkmıyorlar. Bu yazılımların sırtını dayayabileceği ekosistem çok daha küçük, yapılan hataların maliyeti çok daha büyük, geliştirme süreçleri geleneksel mühendisliklere çok daha yakın. Son tüketim yazılımlarında yazılımcının ana işinin ürün sahibinin ürettiği gereksinimleri programlara dönüştürmek olduğundan bahsetmiştim, omurga yazılımlarda artık yazılımcının ana uzmanlığı kod yazmak değil, alttaki sistemi anlamak, nasıl geliştirebileceğini keşfetmek, kod artık bir araç değil, aynı zamanda bir amaç haline geliyor.

Buraya kadar adını vermeden etrafından dolaştığım bir konsepte gelelim, soyutlama (abstraction). Bahsettiğim "sırtını dayama" konsepti aslında sırtımızı dayadığımız yazılımların bizim için belli detayları soyutlaması sayesinde mümkün oluyor. Her soyutlama katmanı bize belli garantiler sağlıyor, veri tabanları koyduğumuz veriyi tekrardan geri alabileceğimizi garantiliyor, PDF yaratmak için kullandığımız kütüphane en son ürettiği dökümanın geçerli bir PDF dosyası olduğundan emin oluyor, uçuş kontrolü için kullandığımız modül uzayda X-Y-Z yönüne doğru ilerlemek istediğimizde fiziksel olarak o yönde ilerlememizi sağlıyor. Soyutlama katmanlarının bize sağladığı garantiler sayesinde büyük yazılım projeleri üretebiliyoruz, mesela iki cihaz arasında tüm mesajların kesin bir şekilde problem yaşanmadan gitmesini sağlayacak fiziksel bir altyapı oluşturmak mümkün değil, ama var olan fiziksel altyapıların üstüne mantıksal olarak mesajların kesin bir şekilde iletimini sağlayan TCP gibi protokoller sayesinde mesaj iletimini bir problem olarak düşünmekten kurtulabiliyoruz. TCP'nin kendisini geliştiren kişiler bizim sahip olduğumuz soyutlamalardan faydalanamıyor, alttaki fiziksel dünya modelinin üzerine bir ağ protokolü kurmak zorundalar. Benzer şekilde veri tabanları, derleyiciler, döküman editörleri, ağ protokolleri, gerçek zamanlı video işleme modülleri... gibi başka uygulamaların onlara sunacağı soyutlama katmanlarından yararlanamayan, makinenin önbellek yapısını, hafızasını, bir programın makine kodunda nasıl gözüktüğünü anlaması gereken pek çok yazılım sınıfı var.

Bu endüstrilerde maaş artık yalnızca gereksinimleri koda dönüştürebilmenin yanında gereksinim üretebilmeye dayanmaya başlıyor, tüketim yazılımlarında daha çok alan uzmanlarının ürettiği gereksinimlere uyulmasından sorumlu olan yazılımcılar artık kendileri de alan uzmanı oluyorlar, çünkü dizayn edilen sistemin güvenebileceği soyutlama katmanları yok, makineyi, algoritmaları, protokolleri anlamak zorundasınız, nasıl ki bir otomotiv mühendisi matematiksel modellemeler yapıyorsa, bir inşaat mühendisi yaptığı binanın yıkılmayacağından emin olmak zorundaysa, siz de veri tabanınızın veri kaybetmediğinden, kullanıcılara verdiğiniz garantilerin gerçekten garantiler olduğundan emin olmak zorundasınız.

Dipnot: Burada kendimi yanlış anlaşılmalara karşı biraz korumak istiyorum. Bir işin mühendislik içermiyor ya da gerektirmiyor olması o işin önemsiz olduğu ya da kolay olduğu anlamına gelmiyor. Demek istediğim şey matematik ve optimizasyon gerektirmediği. Benim de günlük hayatımda yazdığım kodların çok büyük bir kısmı matematik gerektirmiyor, hatta bilgisayar mühendisliği eğitimi de gerektirmiyor, kendime programlama öğretsem yapabilirdim çok büyük bir kısmını. İşin geri kalan küçük kısmında matematik bilmeye ihtiyacım var, eğitimimi de onun için kullanıyorum, bu yazıyı okuyacak öğrencilerin de aynısını yapacaklarını, aldıkları eğitimin boşa olmadığını, endüstride karşılığını olduğunu bilmeleri için bu yazıyı yazmak istedim biraz da.

Açık Kaynak

Yazılımın ekonomisini konuşurken açık kaynağın buradaki rolünü konuşmamak olmaz, çünkü yazılımı diğer endüstrilerden ayıran en önemli faktörlerden birisi açık kaynak kültürü. Çoğu endüstride ticari sır olarak nitelendirilecek uygulamalar, ürünler, fikirler açık olarak paylaşılıyor, geliştiriliyor. Linux, SQLite, Chromium, Kubernetes gibi endüstrinin çok büyük bir kısmını güçlendiren ürünlerin yanı sıra popüler tüm programlama dillerinin derleyicileri, editörler, TensorFlow/PyTorch gibi endüstri standardı makine öğrenmesi kütüphaneleri, internetteki sitelerin çok büyük bir kısmının arkasında olan Wordpress, Netflix ve Youtube'un video işleme için kullandığı ffmpeg gibi yüzlerce inanılmaz değerli uygulama ve kütüphane açık kaynak, çoğunun lisansları üstlerine iş kurulabilecek esnek lisanslar.

Açık kaynakla ilgili tartışmaları çoğu zaman ekonomiden bağımsız görsem de, benim gözümde açık kaynak her projenin ekonomik olarak da sürdürülebilir olması gerekiyor, çünkü ekonomik olarak sürdürülemeyen bir sistem ancak öğrenciler, tam zamanlı çalışmak zorunda olmayan gönüllüler, ya da tam zamanlı işinin üzerine açık kaynak projeleri bir şekilde devam ettirebilen inanılmaz özverili insanlar sayesinde devam edebiliyor. Çoğu zaman, eğer proje insanlara finansal fayda sağlayabiliyorsa şirketler üzerine ücretli bir ürün kurarak projenin açık kaynak kısmını fonlayabiliyorlar, benzer şekilde büyük açık kaynak projelerde yer almanın getirdiği endüstrideki sosyal kredi hem şirketlerin alım süreçlerinde hem de endüstrideki çalışanların verdikleri kararlarda etkili oluyor. Şahsen ben açık kaynak bir projede çalışabileceğim bir şirketi kapalı bir projeye tercih edebilirim. Tabii bunun üzerine açık kaynağın manevi bir tarafı olduğunu da yadsımamak önemli, pek çok insana direkt olarak faydası olan bir proje üzerinde çalışmanın şahsi bir tatmini de var.

Açık kaynağın yazılımda popülerleşmesinin tarihsel geniş bir bağlamı var, ancak ben yine ekonomik taraftan yaklaşmak istiyorum. Yazılım ürünlerinin üretim ve bakım masraflarının neredeyse tamamı emekten oluşuyor, geleneksel endüstrilerdeki materyal veya lojistik masrafları kendilerini farklı şekillerde yazılım endüstrisinde ortaya çıkarsa da çok daha küçük ve göz ardı edilebilir kalıyorlar. Ana masrafın emek olması sebebiyle herhangi birimiz kendimizin, çevremizin, ya da toplumun bir kesiminin problemini çözecek bir çözüm üretip bunu yayabiliyoruz. Bugün özellikle programlamada bize yardımcı olması için kullandığımız pek çok mini araç 2-3 kişinin kendi problemlerini çözmek için üzerine çalışmaya başladığı araçlar, zaman içerisinde endüstri geneline yayıldıkları için her cihazda, her an, ücretsiz bir şekilde kullanabiliyoruz bunları.

Maaşlar

Buraya kadar endüstrinin farklı parçalarının ne gibi işler yaptığını, farklı alanlarda yazılımcının hangi kabiliyetlerinin onu iş sahibi yaptığını konuştuk. Peki farklı segmentlerdeki maaş dengeleri nasıl ortaya çıkıyor? Tabii ki genel geçer belli bilgilerimiz var, Amerika'daki ortalama maaşın yüksek olduğunu biliyoruz, bunun ülkedeki yazılım endüstrisine yapılan yatırımın ve edilen dudak uçuklatıcı karların bir sonucu olduğu çıkarımına varabiliyoruz. Peki Avrupa'da, Türkiye'de nasıl ortaya çıkıyor maaş dengeleri? Benim endüstrisindeki maaşlarla ilgili gördüğüm en iyi araştırmayı ve modeli 2021 yılında Gergely Orosz pragmatic engineer adlı bloğunda yayınladı. Gergely bu yazıda endüstriyi 3 parçaya ayırıyor, T1 şirketleri en fazla pozisyona sahip, en az maaşları veriyorlar, maaşları için kendi alanlarındaki lokal şirketler ile yarışıyorlar. T2 şirketleri maaşları için tüm lokal şirketler ile yarışıyor, T3 şirketleri ise en az miktarda çalışan alıyor, bölgesel ve küresel şirketler ile yarışıyor.

Analizin detayı için asıl yazıyı okuyabilirsiniz, ancak ben biraz daha kendi perspektifimden sunmak istiyorum. Tek kişilik bir şirket hayal edelim, aylık belirli bir miktarda geliri var, giderleri var, günün sonunda karı da X lira olsun. Bu şirketi büyütmek için kişinin ya yeni büyümeyle birlikte uzun vadede daha fazla satış yaparak karını arttırabileceğine, ya da yapmak istemediği işleri karının belli bir miktarını keserek başkasına yaptırabileceğine inanıyor olması gerek. Buradaki seçeneklerden ilki çalışanı yeni kar üretiminin bir parçası olarak görürken, ikincisinde çalışan bir maliyet, işveren her zaman çalışanı ortadan kaldırarak yapmak istemediği işleri yapıp maliyetini eski haline düşürebilir.

Benim endüstriye bakışım bu ikilemde her zaman kar üretiminin bir parçası olmaya çabalamak yönünde, bu da büyüyen, büyümek isteyen şirketlerde yer almak, kendini endüstrinin kalanından mümkün olduğunca ayrıştıracak şekilde kabiliyetler edinmek, şirketlere o ayrıştırdığım yönü bir artı olarak sunmak, birinin yapmak istemediği işleri yapmak yerine yapamayacağı işleri yapabilmeye çalışmak oldu. Tabii ki endüstri 1 kişiden 2 kişiye çıkacak şirketler ekseninde tartışılabilecek kadar basit değil. Savunma sanayii, bankalar gibi kurumsal şirketler taşa yazılmışcasına sabit maaş aralıkları sunuyor, pek çok şirket Gergely'nin T3'ünde yer alabilecek kadar büyük bir ölçekte çalışmıyor, o şirketlerle yarışmasına gerek kalmıyor, ülkedeki genel ekonomik durumla uyumlu seviyede maaşlar veriyorlar, ancak Türkiye'de de küresel ölçekte çalışan, küresel yarışın bir parçası olan, T3 grubunda şirketler var.

Yapay Zeka

Yazının başında bu yazının "yapay zeka işimi alacak mı" korkusunu yaşayan öğrencilere faydalı olmasını umduğumdan bahsetmiştim. Bitirmeden önce biraz ona değineyim. Fark etmiş olabilirsiniz, yazı boyunca endüstriyi farklı şekillerde kategorize ettik, tüketici yazılımlarından, bu yazılımları destekleyici konumda olan omurga yazılımlara bir geçiş yaptık, bunun haricinde T1-3 eksenlerinde şirketlerin yarıştığı ölçekleri kategorize ettik. tüketici yazılımlarını da kendi içerisinde spesifik problemlere odaklanan mikro yazılımlardan makro yazılımlara bir spektrum olarak niteledik. Bu mikro-makro skalasında ilerledikçe nasıl problemlerin ortaya çıktığını, yazılımcıların spektrumun farklı noktalarında farklı problemleri çözdüğünü tartıştık.

Bundan birkaç ay önce Yeni Sınır Doğrulanabilirlik (Verifiability is the Limit) adında, temele yapay zekanın yeni kabiliyetlerinin endüstriyi nasıl etkileyeceğini düşündüğüm bir yazı yazmıştım, burada tamamını tekrarlamayacağım, ama ana argümanı tekrarlamak yararlı.

Yazdığınız her türlü program, ürettiğiniz her türlü ürün, birilerinin işine yaramak için var. Dolayısıyla onun sizin kabul edilebilir bulduğunuz sınırlar içerisinde "doğru" olduğunu doğrulamanız gerekiyor. Bir nükleer santral, araba ya da apartman, ya da bir omurga yazılım için bu doğrulama çok daha fazla mühendislik gerektirebilir, çok daha fazla matematiğe ve efora ihtiyaç duyabilir, ancak bir web sitesi için de sizin bakıp istediğiniz gibi gözüktüğünden emin olmanız gerek. Doğrulama sizin yapay zekaya atayabileceğiniz bir görev değil, çünkü ne olursa olsun en son noktada sizin modelden doğal dille istediklerinizin modelin anladığıyla aynı şey olduğundan emin olmanız mümkün değil.

Yazıda doğrulamanın farklı alanlarda nasıl olduğu, bunun yapay zeka kullanımını nasıl etkilediğine dair başka tartışmalar da var, en sevdiğim yazılarımdan birisi, okursanız sevinirim. Buradan endüstri analizine geri dönebiliriz.

Yapay zeka öncesi dönemde programlama yeteneği bir ek değerdi. Yani maaşlar kısmında bahsettiğim şirkete maliyet olmak yerine daha fazla para kazandırma fırsatı verdiğiniz bir pozisyonda oluyordunuz kod yazan kişi olarak, çünkü "kod yazabilenler" ve "kod yazamayanlar" olarak ikiye ayırabilirdik toplumu. Artık "kod üretmenin" kolaylaşması ile birlikte bu ayrım ortadan kalktı, ancak "kod doğrulayabilenler" ve "kod doğrulayamayanlar" ayrımı hala var. Yeni Sınır Doğrulanabilirlik yazısında bahsettiğim gibi, doğrulama her alanda farklı şekillerde yapılıyor, bazı alanlarda doğrulama yapmak için bugün QA (Quality Assurance) alanında çalışlanların yaptığı tarzda program ile çeşitli interaksiyonlara girerek programın tepkilerini ve cevaplarını inceleyip izlemek yeterliyken, diğer alanlarda bir programı doğrulamak için yine farklı programlar yazmanız, sistemin matematiksel modelini anlamanız gerekebiliyor. Benim gözümde artık doğrulama yapmak için programla yalnızca interaksiyona girmenin yeterli olduğu alanlarda programcı olmak bir maliyet haline geldi bir değer olmak yerine, bu da bu pozisyonların ortadan kalkacağını, maaşlarının düşeceğini gösteriyor bana.

Endüstrinin bunun dışında kalan kısımlarına bakarsanız üretilen değerin doğal dille ifade edebileceğiniz problemleri koda dökmek olmadığını görebilirsiniz. İlk başta o problemleri keşfetmek, anlamak, çözüm yöntemi üretmek bir değer, ürettiğiniz kodun diğer kişiler tarafından okunabilir, geliştirilebilir, büyütülebilir olduğundan emin olmak bir değer, ürettiğiniz kodun fonksiyonel olmanın yanında performans, güvenlik gibi gereksinimlere uyduğundan emin olabilmek bir değer, bu değerlerin çok ciddi bir kısmı "doğrulama" ile geliyor, "üretim" ile değil.

Krediler

Yazıya dair yorumları, eleştirileri ve tavsiyeleri için Ahmet Öğreten, Ahmet Yüksel, Arda Çelik, Barış Aşkın, Cemil Vahapoğlu, Doğaç Eldenk, Emre Güllü, Göktuğ Ekinci, Ozan Erdem, Türker Akpınar, ve Umut Güllüoğlu'na teşekkürler.

Kapanış

Biraz dağınık bir yazı oldu, endüstrinin farklı taraflarındaki benim biraz geç fark ettiğimi düşündüğüm bakış açılarımı ortaya dökmeye çalıştım. Belki de ben biraz naifimdir, bilgisayar mühendisliği öğrencileri ya da endüstri ile daha iç içe yazılım mühendisleri bunların daha çok farkındadır, belki de benim farkındalıklarım çok da doğru değildir. Kısaca toparlamak gerekirse, dünyadaki en büyük endüstrilerinin bir tanesinin içerisindeyiz. Çok farklı iş kolları, çok farklı pozisyonlar, çok farklı şirketler var, hepsinin çeşitli dinamikleri, beraber iş yaptıkları farklı şirketler, hizmet sağladıkları çeşitli sektörler var, toplu bir şekilde baktığımızda milyarlarca doların döndüğü inanılmaz kompleks bir endüstriden bahsediyoruz. Bu endüstrinin içerisinde bir birey olarak yer alırken ekonomik dinamikleri anlamaya çalışmak bana eğlenceli geliyor, bir yandan da şirketlerle olan iletişimlerimi yönlendiriyor, hangi tip şirketlerle nasıl iletişim kurmalıyım, bu şirketler için ne değerli, yapacağım iş bundan nasıl etkilenecek onu anlamak için bana faydalı olduğunu düşünüyorum, bence endüstride yer alıyorsanız sizin de bunları düşünmeniz sizin için de faydalı olacaktır, kolay gelsin.

*: Bilgisayar bilimi ve mühendisliğiyle ilgili ilginç başka fikirleri takip etmek istiyorsanız Hafif Programming'i kaçırmayın.