Fast - Hızlı Yazılımın Gücü

• Yazılım geliştirmede hız (fast) nadiren açıkça talep edilir, ancak hızlı yazılım kullanıcı davranışını değiştirir
• Hızlı dağıtım ve gerçek zamanlı streaming gibi teknolojiler iş verimliliğini ve uzaktan çalışmayı kökten iyileştirir
• Yavaş yazılım bilişsel sürtünme yaratır ve kullanıcı üretkenliğini gerçekten ciddi biçimde düşürür
• Hızlı yazılım karmaşıklığı gizlemez; sadelik ve odak gösterir
• Gelecekte geliştirme sektöründe performans ve deneyim optimizasyonuna verilen önem daha da artacak

---

Hızın talep edilmediği yazılım sektörü

• Yazılım sektöründe çoğunlukla özellikler, fiyat, veri entegrasyonu gibi şeyler talep edilir; “hız” ise doğrudan nadiren istenir
• Ancak hızlı yazılım, kullanıcı davranışını bizzat değiştirme gücüne sahiptir
• Kod dağıtım süresi saniyelere indiğinde geliştiricilerin dağıtım sıklığı da artar
• Yapay zeka tabanlı kod otomatik tamamlama özellikleri, aşina olunmayan dillerde prototiplemeyi kolaylaştırır
• Gerçek zamanlı streaming teknolojisi uzaktan çalışmanın önünü açar

Yavaş yazılımın sınırları

• Yavaş yazılım, düşündüğümüzden daha fazla kısıt yaratır
• Örneğin uçak WiFi kullanırken büyük işler başarmanın zor olduğu bir deneyim yaşanabilir
  • Ancak Slack mesajı göndermek veya e-postalara yanıt vermek mümkündür
  • Google Docs ise çoğu zaman düzgün çalışmaz
  • Sonunda vazgeçilen bir kullanım deneyimine dönüşür
• Buna karşılık Instagram gibi hizmetler tutarlı biçimde hızlı bir deneyim sunar

Hızlı yazılımın etkisi

• Hız, sihirli bir his verir
• Hızlı yazılım bilişsel sürtünmeyi ortadan kaldırır ve Raycast veya Superhuman gibi beklenenden bir adım önde tepki verir
• Superhuman’ın 100 ms altı yanıt süresi ve güçlü kısayol desteği, e-posta kullanım deneyimini dönüştürür
• Mercury’nin anında transfer özelliği de yavaş bankacılık işlemlerine alışmış kullanıcılar için şaşırtıcıdır
• Bu araçların hızı açıkça övülmez; ama kullanıcıların bunu adeta sihir gibi hissetmesinin nedeni budur

Hız, sadelik ve odak

• Hız aynı zamanda sadelik demektir ve bu, modern yazılım dünyasında giderek daha nadir bulunan bir değerdir
• Yazılımın hızlı olabilmesi için gereksiz özellikleri kaldırmaya yönelik çaba gerekir
• Linear gibi yalın proje yönetimi araçları, Workday ve Oracle gibi kurumsal uygulamalara kıyasla çok daha hızlı bir kullanım deneyimi sunar
• Hız, kullanıcıya duyulan saygının bir göstergesidir; gereksiz unsurların titizlikle ayıklandığını gösterir

Hızlı yapmak için gereken görünmez çaba

• Hızlı yazılım üretmek için karmaşık backend optimizasyonları gerekir
• Cash App’te, kullanıcı yolculuğuna yalnızca gerçekten gerekli adımları eklemeye çalışılır; karmaşıklık ise içeride yönetilir
• Instagram, fotoğraf yüklerken altyazı girilirken aynı anda yüklemeyi başlatarak kullanıcıya yüklemenin anında başladığı hissini verir
• Hız, basit bir teknik başarı değil; önceliklendirme ve odağın sonucudur

Hız eğlence ve motivasyondur

• Hızlı yazılım kendi başına eğlence ve tatmin sağlar
• Yazma hızı (WPM) ölçümü veya kısayol ayarlama gibi küçük ayrıntılarda bile kullanıcılar hızlanma deneyiminden keyif alır

Hızın göreliliği

• AI ve LLM tabanlı iş akışları, geleneksel yöntemlere kıyasla çok daha hızlı bir deneyim sunar
• Örneğin, bir LLM’ye 6 dakika içinde araştırma yaptırmak, geçmişle karşılaştırıldığında 10.000 kattan fazla daha hızlı bir üretkenlik yaratabilir
• Ancak AI uygulamalarının geliştirme, build ve dağıtım süreçlerinde hâlâ önceki yazılım dönemine kıyasla eksik kalan birçok nokta vardır
• Şu anda odak, performans ve deneyimden çok yeni özellikler üzerindedir
• Gelecekte düşük gecikme, arayüz tasarımı, bağlantılılık ve güvenilirlik gibi optimizasyonların önceliklendirildiği bir eğilim gelecektir
• Böylece daha fazla yeni olasılık ve kullanıcı deneyiminin evrimi mümkün olacaktır

Referanslar

• Hız konusunda faydalı ek kaynaklar olarak şu yazılar bulunuyor
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Hacker News görüşleri

• YCom'un HN arayüzünü hızlı ve iyi durumda tutmasından gerçekten memnunum. Slashdot "modern UI" diyerek arayüzü tamamen değiştirdikten sonra aşırı boşluklu ve taraması zor bir yapıya dönmüştü; ben de hemen bırakmıştım. Eskiden her gün okuduğum bir siteydi
  • Bilgi yoğunluğu ve istenen bilgiyi hızlı bulmak, "engagement" kavramının tam tersidir. Genelde sitede kalma süresi metriklerini artırıp reklamverenlere hoş görünmek için özellikle karmaşık hale getiriliyor. Sayfa bilerek yavaş yükleniyor, yanlış tıklamaya neden oluyor ve "dönüşüm" sağlamaya çalışıyor. Gerçekte kullanıcı odaklı olmaktan çok insanları kandırmak daha çok para kazandırıyor
  • HN, internet bağlantısının çalışıp çalışmadığını kontrol etmek için açtığım site. Bunca web şişkinliğinin arasında gerçekten parlayan bir yer
  • HN arayüzünün, özellikle mobilde, iyileştirmeye ihtiyacı var. Kontrast düşük, butonlar fazla küçük olduğu için kullanımı zor, dark mode yok vb. Benim ideal arayüz anlayışıma göre Elm ile, tamamen client-side çalışan ve HN firebase API kullanan bir sürüm var: https://seville.protostome.com/
  • Slashdot'un çöküşünün sebebinin arayüz olduğunu sanmıyorum. Asıl değer, çok erken dönemdeki yüksek kaliteli SME'lerin bıraktığı yorumlardaydı. Site satıldıktan sonra düşük kaliteli kullanıcılar, kötü yönetim ve kullanıcı kaybıyla düşüş başlamış gibi görünüyor. Sitenin hâlâ yaşıyor olması şaşırtıcı
  • orange site (HN) hâlâ Markdown link etiketlerini desteklemiyor
• LLM eklenen iş akışlarının gerçekte çoğu zaman daha yavaş olduğunu düşünüyorum. IDE'deki "refactor" özelliği 1 saniyede bitiyor ama yapay zeka yardımcısına verirseniz 30 saniye, "agent" tarzında kullanırsanız 15 dakika sürebiliyor. Mesela bir agent'a HTTP endpoint kodu yazdırdım; ilk anda "bir günlük işi 10 dakikada bitirdi" diye düşündüm ama sonra bakınca mantık karışmıştı ve hata yönetimi de zayıftı. Sonuçta yaklaşık 5 saatimi verip kodu baştan yazdım; testleri benim standardıma göre daha iyi hale getirdim ve hata işleme de kendi başına yapacağından daha iyi bir seviyeye geldi. Bununla ilgili bir araştırma da var https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Bu konuda daha önce birkaç kez yazmıştım. LLM'lerin benchmark puanlarının peşinden gitmesinin, programlama araçları açısından yanlış yönde olduğunu düşünüyorum. Benim deneyimimde oldukça yüksek olasılıkla hata yapıyorlar; bu yüzden çıktıyı her zaman kontrol etmek gerekiyor, LLM ile gidip gelme süresi uzuyor ve yanıtlar yavaş geldiği için çoğu zaman elle kendim daha hızlı yapabilirmişim gibi geliyor. Benim istediğim şey, benchmark'ta %60 seviyesinde kalsa bile 1 saniyenin altında yanıt veren bir agent
  • LLM'in işimi gerçekten hızlandırdığı tek alan, kod için gelişmiş bir find/replace kavramı oldu. Örneğin kodun farklı yerlerindeki "XXX ile ilgili mantığı" başka bir şeyle değiştirmesini istemek gibi komutlara gayet iyi cevap veriyor. Tek tek bulup değiştirmenin zahmetini ciddi biçimde azaltıyor. Ama çok büyük kod tabanlarında denemedim
  • Sanırım duruma göre değişiyor. Refactor işlerinde IDE veya language server destekliyorsa çok daha hızlı, ama onun dışında LLM de yardımcı olabiliyor. Örneğin dün URL normalizasyon mantığını bir MVP olarak yazıyordum ve müşteri verilerinde çok farklı URL biçimleri karışık olduğu için doğrulama vakası fazlaydı. En sık görülen müşteri örneklerini Claude'a verip "minimum spanning test cases" oluşturmasını istedim; 5-10 saniyede sonuç verdi. Sonra bunu temel alarak Zed'in Opus agent özelliğiyle test dosyasını oluşturdum, vakaları gözden geçirip gereksiz kısımları temizledim ve mantığı biraz daha iyileştirdim. Bu yöntem her şeyi tek başıma yapmaktan çok daha hızlıydı
  • Kıdemli seviyedeki işlerde hızın %40-60 arttığını hem çevrim içi hem çevrim dışı çok duyuyorum. Yine de henüz sadece AI agent'lara güvenip her şeyi onlara bırakacak noktada değil gibi
• Genç bir yazılım mühendisi olduğum dönemde, hızı artırma konusunda ün kazandığım bir anı. O zamanlar hem algoritma bilgisi hem de compiler çıktısını okuyabilme yeteneğinin önemli olduğu, Carmak ve Abrash gibi isimlerin yıldızlaştığı bir dönemdi. 22 yaşındayken ilk kez büyük çok uluslu bir kurumsal müşteri toplantısına katıldım ve ürünümüzün hızının sorun olduğu söylendi. Şirketteki bir VP'nin, "1 saniyelik iyileşme bize yılda 1 milyon dolar ek kâr getirir" dediğini doğrudan duymak beni ciddi biçimde sarstı. Hıza parayla bu kadar doğrudan değer biçildiğini ilk kez orada görmüştüm. Aradan 20 yıl geçti, hâlâ kariyerimin en unutulmaz anlarından biri. Sonra başka bir mühendis VP'ye "peki 0 saniyeye indirirsek sonsuz para mı kazanırız" diye şaka yaptı; odada kimse gülmedi ama ben oldukça komik bulmuştum
  • 1 saniyeden 0 saniyeye ya da 2 saniyeden 1 saniyeye inince her seferinde 1 milyon dolar artacaksa, bunun illa sonsuz paraya gitmesi mantığı biraz tuhaf değil mi?
  • Sonunda gerçekten hızlandı mı, merak ettim
• Blog yazısının ilk cümlesine katıldığım için bunu yazıyorum. Kullanıcılar geliştiricilere doğrudan "bunu hızlı yapın" demez ama hızlı değilse de güvenmezler. Rust, Ruby'den yavaş olsaydı kimsenin ilgisini çekmezdi. Rust'ın "C++'tan daha hızlı" denmesi dikkat çekiyor. HN'de de sadece "hızlı" olması bile insanları büyülemeye yetiyor. Biraz daha hızlı dense hemen ilgi görüyor
  • Bu daha çok HN'de yazan küçük bir programcı kitlesi için geçerli. Çoğu geliştirici ya da sıradan kullanıcı yavaşlığı çok umursamıyor; arayüz rahat olsun yeter. Profesyonel veri bilimcileri bile süper hızlı komutlar yerine çoğu zaman düzenli görünen Github Desktop kullanıyor
  • Sonuç yanlış gibi. "Hız", aynı özellik setini daha hızlı sunabildiğinde güçlü bir farklılaştırıcı oluyor. İnsanlar "X'ten daha hızlı X"e koşabilir ama daha fazla özellik, daha iyi UX, daha ucuz ya da genel olarak daha iyi bir şeye de geçebilirler; yavaş olsa bile tercih edilebilir
  • Diller ve runtime'larda hız önemli ama framework kullanırken özellikler, uyumluluk gibi başka unsurlar daha önemli olabiliyor. Electron gibi yavaş şeyler de yaygın kullanılıyor
  • Gerçekte, özellikle web uygulamaları olmak üzere pek çok uygulamanın aşırı yavaş olduğu bir dünyada yaşıyoruz. Kullanıcı bir şey yaptığında tepki gelmesi saniyeler sürebiliyor. "En iyisi hızlı olandır" denilse de pratikte durum çoğu zaman bunun tersi
  • HN kullanıcılarının 'hız'ı sevmesinin nedeni, bugün kullandığımız teknolojilerin çoğunun fazla yavaş olduğunu ve aslında özünde daha hızlı yapılabileceklerini biliyor olmamız
• Tersine, bir şey "fazla" hızlı olduğunda gerçekten çalışıp çalışmadığından şüphe duyma durumu da var. TurboTax örneğinde gerçek analiz 1 saniyeden kısa sürüyormuş ama bilerek sahte bir yükleme ekranı koyduklarında insanlar daha çok güvenmiş ve daha çok beğenmiş. Yani gerçek işlem süresi çok daha kısa olsa da "gerçekten kontrol etti mi" güveni için daha yavaş görünmesi sağlanmış
• Hız, maliyet açısından da önemli. Bulutta saniye bazlı ücret ödendiğinde, her adımı optimize etmeden ucuz bir transcription hizmeti vermek mümkün olmuyor. Örneğin yaptığım imaj, bir açık kaynak alternatifine kıyasla 2,5 kat daha küçük hale geldi; bu da daha hızlı cold boot, daha düşük maliyet ve daha iyi hizmet anlamına geldi https://speechischeap.com
  • S3 yavaş mı hızlı mı? Aslında ikisi de. Tek bir request açısından yavaş ama paralel çok sayıda request attığınızda hızlıymış gibi hissediliyor. Sonuçta 'hız' bazen hayatta kalmak için kritik, bazen de bir estetik meselesi
  • Ben ise tam tersine, hizmetleri consumer donanım üzerinde çalıştırıp buluttan çok daha ucuza işletiyorum. İmaj boyutunu dert etmeme gerek kalmıyor (bare metal daha hızlı). Dakikada 20 bin dakikalık transcription'ı ücretsiz sunuyorum (istek başına 5 saniye sınırıyla). Bununla ilgili açık kaynak ve çapraz platform alternatifler de geliştiriyorum https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer transcription hizmetlerinde devrimle ilgilenen varsa iletişime geçebilir
  • PAPER gibi araçların, en azından Linux'ta, toplam kurulum boyutunun 2MB altında olmasını bekliyorum; buna cache de dahil. pip 10-15MB, pipx daha da büyük, uv ise 35MB. Ben bunu daha aşağı çekmeye çalışıyorum
  • Hızlı olması, her zaman hafif ve verimli olduğu anlamına gelmez. Bazen çok güçlü ve pahalı donanımlar yığılıp hız elde edilir
• ABD'deki banka havaleleriyle ilgili bir şikâyet gördüğümde bunu hep kendime hatırlatmam gerekiyor. Birleşik Krallık veya İsviçre gibi yerlerde banka transferleri neredeyse anında tamamlanıyor. ABD'de neden bu kadar yavaş olduğunu merak ediyorum
  • ABD'deki bölgesel bankaların neredeyse hiç kendi programcısı yok ve "core processor" sağlayıcılarına bağımlılar. Bu yüzden sistem yükseltmeleri çok yavaş ilerliyor. Faster ACH'nin devreye alınması bile yıllar sürdü ve bölgesel banka lobileri bunun kendilerine zarar vereceğini söyleyerek geciktirilmesini savundu. Bunu iyi anlatan bir blog yazısı var https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • Yavaşlığın bir nedeni ACH'nin zamanlama ve batch mantığı. Transferin kendisi hemen tamamlansa bile, çoğu zaman gece yarısında toplu olarak işleniyor. Bu yüzden ABD'de Venmo ve Zelle popüler. İsviçre'de de IBAN transferleri yavaş; gerçek zamanlı ödemelerde TWINT öne çıkıyor (QR kod tarama biçimiyle). Birleşik Krallık'taki BACS de aynı nedenle yavaş
  • ABD'de fiilen iki gerçek zamanlı para transfer sistemi var: RTP ve FedNow. Katılan banka sayısı giderek artıyor https://real-timepayments.com/Banks-Real-Time-Payments.html Eskiden küçük bir ücret ödeyerek kredi kartı ağı üzerinden anında para göndermek de mümkündü. Ancak kredi kartlarında garanti ve chargeback kuralları farklı, ayrıca dolandırıcılık durumunda bankanın zararı daha büyük
  • Bunun tüketici açısından olumlu bir yanı da var. Mesela otomatik ödeme talimatıyla bakiyesi olmayan hesaptan para çekilmeye çalışıldığında banka birkaç kez e-posta gönderiyor. Her şey gerçek zamanlı olsaydı anında sorun çıkardı; oysa şimdi bildirim alıp kendiniz önlem almak için zamanınız oluyor, böylece gecikme veya ceza ücretlerinden kaçınabiliyorsunuz. Anında transfer olmaması, bankanın haber vermesi ve benim müdahale etmem için fırsat tanıyor
  • patio11 bu konuda ayrıntılı bir yazı yazmıştı https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• Yazı ilginçti ve epey düşünme malzemesi verdi. Hızın gerçekten hissedildiği yer, gerçek throughput'tan çok "hissedilen hız"; yani UI tepkiselliği veya input gecikmesi gibi rahatlık duygusu veren kısım. Bu yüzden Go'yu Rust'tan daha çok seviyorum. Go'nun compile hızı yeterince yüksek; sanki ölçmeye gerek bile yokmuş gibi. Tersi durumda, bir şey yavaş hissettiriyorsa gerçek throughput'u yüksek olsa bile hoşuma gitmiyor (Java startup'ları gibi)
  • Go ile Rust'ı karşılaştırırken compile hızının gerçekten önemli olduğu hissediliyor. Rust build'lerinde çok sayıda dağınık dependency var; proje yapısı bu açıdan JavaScript'e benziyor. Go'da kıyasla dependency çok daha az, bu yönünü seviyorum
  • Geliştiricilerin bu tartışmaları yapması güzel ama asıl önemli olan, "kullanıcıya hangi dil daha hızlı geliyor" sorusu
• "Yazılımda 'bunu hızlı yapın' sözünü pek duymayız" denmesine rağmen, çalıştığım neredeyse her şirkette sayfa tepki süresi ve latency en üst öncelikler arasındaydı. İster startup ister büyük şirket olsun, hız ve latency önemli hedeflerdi; ürünün ne kadar hızlı olduğu, sayfanın ne kadar çabuk açıldığı ve garip gecikmeler olup olmadığı her zaman önemli görülürdü
  • Benim doğrudan deneyimlediğim şirketlerin çoğunda (8 şirketin 6'sında), performans optimizasyonu için neredeyse hiç zaman verilmezdi; bu yüzden hep gizlice araya sıkıştırırdım. Hatta latency ölçüp bunun önemli olduğunu söyleyen yerlerde bile, iş gerçek özellik geliştirmeye gelince performans ikinci plana atılırdı
  • Arama sonuçlarının hızını takıntılı biçimde iyileştirirken, sayfa render süresi veya kullanıcıya gönderilen veri miktarıyla pek ilgilenmeyen çok yer gördüm
• Farklı iş yerlerinde tekrar tekrar gördüğüm bir şey var: Çoğu kişi hızın gerçek değerini hafife alıyor. Bunun nedeni, sadece "aynı iş akışını daha hızlı yapmak" diye düşünmeleri. Örneğin gece boyunca süren büyük bir deneyi hızlandırmanın çok faydalı olmadığını sanıyorlar; ama hız dramatik biçimde artarsa gün içinde aynı deneyi defalarca çalıştırabilir ve bambaşka bir üretkenlik düzeyine çıkabilirsiniz
  • İnsanlar context switch maliyetini çok küçümsüyor. Bir komutu 30 saniyeden 3 saniyeye indirmenin, günde 10 kez çalıştırılıyorsa sadece 5 dakika kazanç getirdiğini düşünüyorlar; ama gerçekte geçiş maliyeti bundan çok daha büyük
  • CI pipeline saatler sürdüğünde, eğer 20 dakika içinde bitseydi o küçük lint uyarılarını bile her seferinde düzeltirdim diye düşünüyorum