Yazılım optimizasyonu öncelik olsaydı, dünyanın daha büyük bir kısmı eski donanımlarla çalıştırılabilirdi
(twitter.com/ID_AA_Carmack)- Yazılım optimizasyonu gerçekten öncelik haline getirilirse, beklenenden daha fazla sistem eski donanımlarda da çalışabilir
- Kıt bilgi işlem kaynaklarında piyasa fiyat sinyalleri devreye girerse, daha verimli yazılım üretme baskısı artar
- Yorumlanan diller ve mikroservisler tabanlı ürünleri monolitik yerel kod tabanı olarak yeniden inşa etmek buna bir örnek olabilir
- Ancak çok düşük maliyetli ve yüksek ölçeklenebilir bilgi işlem olmazsa, yenilikçi yeni ürünleri denemek ve piyasaya sürmek çok daha nadir hale gelebilir
- Performans optimizasyonu tek başına yeterli değildir; ucuz ve ölçeklenebilir bilgi işlem, ürün denemelerinin ve lansman sıklığının belirleyicisidir
Optimizasyon öncelikli düşünce deneyi
- Yazılım optimizasyonu gerçekten öncelikse, beklenenden daha fazla sistem eski donanım üzerinde çalıştırılabilir
- Kıt bilgi işlem kaynaklarında fiyat sinyalleri güçlü biçimde işlerse, piyasa daha verimli yazılım talep eder hale gelir
Olası uygulama biçimi ve kısıtlar
- Bir örnek, yorumlanan diller ve mikroservis tabanlı ürünleri monolitik yerel kod tabanı olarak yeniden yapmak olabilir
- Ancak çok düşük maliyetli ve yüksek ölçeklenebilir bilgi işlem yoksa, yenilikçi yeni ürünler çok daha nadir hale gelebilir
1 yorum
Hacker News yorumları
Piyasanın bol hatalı ve verimsiz yazılımları da olgun yazılımlar kadar satın aldığı, bunlardan birinin üretilebilecek en ucuz yazılım olduğu şeklinde bir mantık kurulabilir
Bu, “limon piyasası” hikâyesine benziyor. Piyasa tüm ürünleri yüksek kaliteliymiş gibi satar ama marjinal maliyeti düşürmek için kaliteyi sessizce aşağı çeker. Alıcı satın almadan önce yüksek kaliteyle düşük kaliteyi ayırt edemediği için talep yapay biçimde benzer hâle gelir; bunun nedeni bilgi asimetrisidir
Yapay zekada bu zaten böyle ve ileride daha da kötüleşecek. Kullanıcılar sofistike bir makine öğrenimi uygulamasıyla çamaşır makinesinin sıkma programına yapay zeka denmesini ayırt edemiyor. Yapay zeka etiketi tek başına fiyat primi yaratıyor ve kullanıcılar çamaşır makinesine ciddi biçimde fazla ödeme yapıyor
Berbat yazılımların mühendisler ve uzmanlar tarafından tasarlanıp yazıldığına inanarak fazla ödeme yapmak da özünde aynı şey. Yazılımların %99’unu IC1~3 seviyesindekiler yazıyor ve çoğu teknoloji şirketinde kaliteyi “kabul kriterlerini karşılıyor” seviyesinin üzerine çıkaran tek mekanizma bir QA çalışanı. Bazen bir grup stajyer “LGTM” büyüsünü okuyor ama o bile nadir
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
Daha iyi bir ürün olursa insanları ikna edeceğinden ve viral büyüyeceğinden emindim, ama öyle olmadı. Büyüdü, fakat o kadar yavaştı ki başa baş noktasına ulaşmadan birkaç yıl içinde paramız bitti
Fark ettiğim şey, rekabetçi bir piyasada düşük maliyetin, dolayısıyla düşük kalitenin rekabet avantajı olduğuydu. Ürün ölçeği büyüdükçe maliyet düşürme baskısı da artıyor; insanlar ucuz olanı istiyor, bu yüzden birileri “maliyeti”, yani kaliteyi kısarak daha ucuza yapıyor. Şirketler hayatta kalmak ve kâr etmek için gereken asgarinin ötesine ödeme yapmıyor
Genç bir şirketin yüksek kalite üretmeye çalıştığı ya da kısa süreliğine harcamayı artırdığı olur, ama sonunda istikrarlı vasatlığa doğru kayan bir akış oluşur. Bu, limon piyasasından biraz farklı; piyasa çöküşünden ziyade her yerde vasatlıkla sonuçlanıyor gibi
Ama ortalama bir kişiye Slack ile hızlı bir IRC istemcisi olan Weechat arasında seçim yaptırsanız, terminal tarzı UI, görüntülü arama yok, webhook entegrasyonu yok, özel avatar veya emoji yok tarafını düşük kaliteli görme olasılığı yüksek
Performans da bir özelliktir. Internet Explorer’ın Chrome’a yenilmesinin büyük nedenlerinden biri, Chrome’un piyasaya çıktığında çok daha hızlı olmasıydı; Python geliştiricilerinin hızla uv/ruff’a geçmesinin nedeni de performans iyileştirmesi. Ancak Slack’in açılması 10 ms yerine 5 saniye sürdüğünde, bunu önemseyenlerin sayısı çok az kalıyor
Hatalı yazılımlarda böyle şeyler yaşanabiliyor, ama genel olarak insanlar daha az ödemek istiyor ve bu süreçte birkaç hatayı göze alıyor. Her kod satırının birden fazla mühendis tarafından incelendiği ve sıkı QA’ya çok zaman ayrıldığı bir süreç izlemek için ne kadar ücret almak gerekeceğini düşünmek yeterli
Padova’da yaşarken küçük bir kitapçı için yazılım yapmıştım; arkadaşım olduğu için hızlıca yaptım ve fazla para almadım. Kusursuz değildi ama sorun çıkınca düzelttim, çok da sorun çıkmadı ve arkadaşım bu alışverişten memnundu. Ucuza yaptığımı bildiği için sabırlıydı da
Ekibimiz müşteriye “proje bitti ama bu back-office platformu kadar çok hata ve UI kâbusu var” deseydi, azar işitip rütbe düşürülür ya da kovulurduk diye defalarca söyledim
Buna insan desteği yetersiz olan Google gibi şirketler de dahil. Destek birçok biçimde ortaya çıkar: dokümantasyon, video, blog gibi bilgiler vardır; “Anne, Google böyle kullanılır” diye yardım eden biri vardır; işletim sistemi, tarayıcı, format gibi kullanım hedeflerine yönelik destek vardır; Excel gibi çalışma biçiminizin kendisini ayakta tutan şeyler de vardır
Son olarak gerçek insanlar vardır. Dünyanın en kötü ERP’sini bile hayatta tutan bir numaralı unsur budur. Pazarlama ve satış da desteğin var olduğuna dair bir sinyaldir. Kurumsal müşteriler yalnızca mühendisleri görüyorsa bu kötü bir işaret olabilir. Geliştiriciler çoğu zaman başka işleri yapamaz; o başka işler de önemli desteklerdir
İyi bir ürün bile destek yoksa ölür. Daha kötü bir ürünle mücadele etmek için ekibimin maliyetini azaltmak adına hata, performans sorunu, platform gibi destek ihtiyacını azaltmak akıllıcadır; ancak başka bir boyutta destek mutlaka eklenmelidir. Küçük ekipler için en kolayı, en kıt destek kaynağı olan insanı eklemektir; sonrasında yaratıcılık gerekir
Ayrıca güçlü yanları iyi anlatmak gerekir. Bazıları “koda sahip olabilmek vs tescilli ürün” gibi belirli bir destek türüne daha çok önem verir. Birçok kişi ise koddansa desteği olan tescilli ürünü daha çok tercih eder
1980’den bu yana bilişim performansının kabaca 1000 kat arttığını düşünme eğilimindeyim.
Dinamik dizi sınır denetimi %5 maliyet getirse bile gerçekte bundan çok daha azdır; her yerde açarsanız bilgisayarlar sadece 950 kat hızlı olur.
1980’e geri dönüp insanlara “950 kat daha hızlı, geniş bir bellek güvenliği açığı sınıfı olmayan ve hata ayıklaması birkaç mertebe daha kolay bir bilgisayar” ile “1000 kat daha hızlı ama yazılımı hâlâ hatalarla dolu ya da daha da kötü, hata ayıklaması kâbus gibi bir bilgisayar” arasında seçim yaptırsaydınız, insanlar 950 katına bile şok olurdu.
Ama bizim seçtiğimiz ikincisi oldu; kişisel olarak 1000 katçılarının geri kalan herkesi mahvettiğini düşünüyorum.
Sonunda onu Sparc 20’de verimli çalışacak şekilde optimize ettiklerinde, şirketin daha geniş pazarda başarılı olmasının zemini oluştu. Optimizasyon rekabet avantajı olarak ele alınmalı; bazı durumlarda en önemli rekabet avantajı bile olabilir.
Bu yüzden sınır denetimini zorunlu kılmak, belirli işlerde o dili rekabet gücünden düşürür.
Çoğu durumda hiç önemli değildir ve %5’ten çok daha küçüktür. Güvenli/güvensiz ya da genel/performans aralığı ayrımı yapmanın iyi bir çözüm olduğunu düşünüyorum.
Ana akım CPU’lar 80’lerin makinelerinden 1 milyon-2 milyon kat daha hızlı olmaya daha yakındır. Birkaç yüz dolara hâlâ milyon kat daha hızlı sınıfında yenilenmiş bir ofis bilgisayarı alabilirsiniz.
Bugün bilgisayarların yavaş olması ve yavaş hissettirmesi, basitçe bilgisayarların yavaş olmasından kaynaklanmıyor; yine de bu yaşanıyor. Betik dillerinin küçük işlemlerde sürekli bellek ayırması ve dinamik tipler yüzünden her değişkende işaretçi takip etmesi bunun nedenlerinden biri; zaten kötü bir ortamda aşırı verimsiz programlar kullanan insanlar da var.
Günümüzde çoğu program, kullanıcının istediği şekilde değil, yazanın çalışmak istediği şekilde yazılıyor. Birçok kişinin optimizasyon kavramına ya da neyin daha hızlı çalışacağına dair sezgisi yok; çalışır hale getirdikten sonra “bu programın hızı buymuş” diye düşünüyorlar.
Aynı yazılımın daha hızlı olabileceği fikrinin kendisi niş bir düşünme biçimi; Hacker News’te bile herkes böyle düşünmüyor.
Çöp toplamalı diller çoğu zaman birkaç kat daha fazla bellek kullanır. Artık kullanılmayan belleği hemen serbest bırakmazlar ve en başta daha fazla ayırmaya ihtiyaç duyma eğilimindedirler.
Google ve Facebook’ta çalışınca donanımın ne kadar ucuz olduğunu ve çoğu durumda kod optimizasyonunun ne kadar az değerli olduğunu bizzat gördüm.
Google, 10 yıldan da önce veri merkezi kaynak kullanımını yönetmeye başlamıştı; her projenin CPU çekirdeği, sabit disk alanı, flash depolama, disk spindle’ı, bellek gibi bütçeleri vardı. Bu kaynaklar genelde birbirine çevrilebildiği için göreli maliyetleri görebiliyordunuz.
O dönemde flash depolama sabit diskten yaklaşık 20 kat pahalıydı, ama spindle darboğazı yüzünden toplam maliyette çoğu zaman daha ucuz oluyordu.
Bunların hepsi “mili-SWE”ye, yani 1 SWE’nin 1 yıl çalışmasının 1000’de 1’i kadar emeğe çevrilebiliyordu. Projeler donanımdan tasarruf edip daha fazla insan alabiliyor ya da daha az insan alıp mevcut bütçe içinde daha fazla donanım alabiliyordu.
Kaç CPU çekirdeğinin 1 SWE’ye denk geldiğini tam hatırlamıyorum ama sanırım binlerceydi. Bir SWE yılını tüm proje optimizasyonuna harcayıp 5000 CPU çekirdeği tasarruf edemiyorsanız net zarar ediyorsunuz demektir.
Çok büyük projeler bundan çok daha fazlasını kullandığı için optimizasyon mantıklıydı; ancak özellikle yazdığınız kodun bir gün değiştirilme olasılığı yüksekse, optimizasyon çoğu zaman doğru seçenek değildi.
Öte yandan web’de genel bir kullanılabilirlik sorunu var. Web’in bugünkü kadar çok kaynak kullanmaması gerekir. Veri girişi işi yapmış birini tanıyorsanız farenin epey verimsiz olduğunu bilirsiniz. 30-40 yıl önceki metin tabanlı terminaller, çok az kaynak kullanırken son derece verimli bir arayüz sağlıyordu.
Bir gün web’in, genel olarak beklenen teknoloji yığınının belirlenip başka sorunlara geçilmesiyle “çözüleceğini” sanıyordum ama öyle olmadı. Hâlâ “haftanın framework’ü” var ve fare tekerleğiyle düzgün çalışmayan kaydırma çubuğunu kullanıcı kodunda yeniden uygulamak gibi aptalca işler yapılıyor. Bu sorunun nasıl çözülebileceğini, hatta baştan “çözülebilir” olup olmadığını bilmiyorum.
Google diğer iki performans yönüne, yani gecikme süresine ve toplam makine kullanım oranına muazzam emek harcadı. İkisi de yukarıdan gelen talimatlardı; binlerce mühendisin zamanını ve dikkatini emdi, işçilik maliyeti de büyüktü.
Ama ekipman kısıtsa, tekil çekirdekler ucuz olsa bile onları sebepsiz yere boş bırakmak istemezsiniz. Çünkü yeni veri merkezi kurulmasını beklemenin fırsat maliyeti büyüktür. Kullanım gecikme süresine çok duyarlıysa, donanım maliyetini azaltmak için değil iş metrikleri yüzünden milisaniyeleri tıraşlamak mantıklıdır.
Değerlendirme marjinal maliyet üzerinden yapılmalı. 1 dolar başına yılda birkaç sent tasarruf ettirecek düzeyde bile olsa, mühendisin boş durmasındansa o işi yapması daha iyidir.
Sorun şu ki neredeyse kimse böyle yapmıyor. Karar alma biçimi ekonomik hesapla ilgisiz ve çoğu kişi sadece “Google’ın yaptığı şeyi” takip ediyor. Bu da pek çok işlev bozukluğunu açıklıyor.
Ama sıradan şirketlerde, hatta büyük şirketlerde bile durum o düzeyde değildir. “Facebook/Google/Netflix vb. ayrı bir sınıftır ve onların uygulamalarının çoğu sizde işe yaramaz” sözünün tipik bir örneği gibi görünüyor.
İnsan kaynaklarını optimizasyona yığan alternatif bir evren hayal edebilirsiniz, ama o evren bugünkünden tamamen farklı olurdu. Optimizasyona bir mühendis daha ayırırsanız özellik geliştiren bir mühendis eksilir. Ne uğruna? Birkaç CPU döngüsü kurtarmak için mi? Güldürmeyin insanı.
Yalnızca başlığa bakınca, Carmack’in doğru optimize edilmemiş yazılımları eleştirip eski donanımlarda performansı iyileştirmeyi savunduğunu sanmıştım.
Asıl tweet ise ikisi de değil; donanım gelişiminin durduğu bir düşünce deneyini ele alıp “çok düşük maliyetli, ölçeklenebilir bilişim olmazsa yenilikçi yeni ürünler elbette çok daha nadir olur” sonucuna varıyor.
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
Aksine, akıllı telefonlardan sonraki 18 yılda pek büyük bir inovasyon görmediğimizi ve bunun, sermayenin tüketiciye özünde zaten sahip olduğu ürünlerle aynı şeyleri satmak için donanım ilerlemesine dayanmasından kaynaklandığını düşünüyorum.
Elbette ilk tweet’ten sonrasını okuyamadım.
Bir durgunluk olur ama kalıcı bir durgunluk olmaz.
Daha az karmaşık dillerle insan işe alıp onları üretken hâle getirebilirseniz, çalışan piyasası genişler ve maliyet düşer.
Orijinal metinde Carmack özünde “iyi ve zeki geliştiriciler pahalı; daha büyük işler olduğu için kodu ve sistemleri sonuna kadar optimize etmelerine para harcanmıyor, bu yüzden yazılım yavaş” demiş oluyor.
Dolayısıyla iyi geliştiriciler birden çok ucuzlarsa, herkesin onları satın alıp optimizasyonda kullanmasıyla pek çok yazılımın birden hızlanabileceği sonucu çıkıyor. Peki iyi geliştiriciler neden birden ucuza bulunabilir hâle gelsin?
Donanım ömrünü “planlı eskitme”den sonra 5 yıl, 10 yıl daha uzatabilsek iyi olurdu.
Böylece elektronik atığı ciddi ölçüde azaltabilir, nadir toprak elementlerini yerin altında bırakabilir ve sera gazı emisyonlarını da büyük ölçüde düşürebiliriz.
Ama yazılım üretimindeki piyasa güçleri bu dışsallıkların bedelini ödemez. Performans için planlayıp tasarlamaktansa hızlıca yayımlamak, test etmek ve yinelemek çok daha ucuzdur. Oyun sektöründeki bazı organizasyonlar iyi performans ile satışları aynı anda elde etmenin formülünü buldu, ama bu yaygın biçimde dağılmadı.
Kurumsal ve tüketici yazılımlarında gereksinimlere performans kriteri koymak için güçlü bir motivasyon yoktur. Kullanıcının dayanabileceği seviyeye göre tasarlanır; değişikliklerin ve özelliklerin sürekli yayımlanması gerektiği için olabildiğince pay bırakılır. Her değişiklik performansı ve kullanıcı memnuniyetini etkileyebilecek bir borç olduğundan, hata oranını kaldıracak bütçe esnekliği sağlanır.
Bu, “hazır olana kadar” kapalı kapılar ardında tasarlayıp geliştirme biçiminden epey farklıdır.
Bakım ve idame odaklı bir ekonomiye sahip olmalı, makro ölçekteki çabalarımızı az sayıda kişinin algılanan zenginliği yerine tüm insanlığın iyiliği etrafında hizalamalıyız.
Eski araçları korumaya, eski bilgisayarları yeniden kullanmaya vb. odaklansaydık, büyümeye kıyasla çöplükler daha küçük olurdu.
Elbette korumacılığın nesnel olarak daha düşük bir strateji olduğunu gösteren oyun teorisi kurguları da muhtemelen vardır.
Bir borsanın tamamındaki emir eşleştirme motorunu tek bir thread üzerinde çalıştırabilmenin üzerinden şimdiden 10 yıldan fazla geçti.
Sıkı biçimde serileştirilmiş işlem yürütme gibi belirli bir hesaplama gücü sınıfının, diğer metriklerin ima ettiği kadar hızlı büyümediğini düşünüyorum. 31 çekirdek daha eklemek emir eşleştirme motorunu hızlandırmaz; hatta yavaşlatabilir.
Ürününüz saniyede birkaç milyonun altında işlem yaparken makine kümesi arıyorsa, yaklaşık 15 adım geri çekilip en baştan başlamanız gerekir.
Oysa özgün tasarım bile kullanım senaryolarının %99’unu hâlâ karşılardı; günümüz yerel bilişim gücü düşünüldüğünde tüm piyasayı tek bir makinede bile çalıştırmak mümkün.
Zaman ve fiyata göre sıralamanın dışında yeterince başka hesaplama olmadığı için mi?
Her işlem için daha karmaşık işleme gerekseydi bu kadar yüksek sayılara ulaşılamazdı. Yalnız, o alandan biri olmadığım için hangi daha karmaşık işlemenin gerekli olabileceğini hayal etmek zor.
Doğru. Bu bir ekonomi meselesi, yani kaynak tahsisi meselesi
Birine yazılım optimizasyonuna daha fazla zaman harcatmak mı, yoksa daha fazla özellik yaptırmak mı; seçim bu. İkincisi daha fazla nakit yaratıyorsa onu yaptırırlar; birincisi nakit akışı için önemli hâle gelirse de onu yaptırırlar
Bu, yazılım şirketlerinin topluma yüklediği negatif dışsallığın açık bir örneği. Çoğu yazılım şirketi enerjinin, kaybedilen zamanın ve ek elektronik atığın gerçek maliyetini ödemediği için optimizasyonu umursamıyor
Titiz optimizasyonun pek anlamlı olmadığı birçok durum da var, ama yeniden yazmak yerine sadece daha fazla sunucu ekleme fikri üzücü bir durum
macOS, Windows, Android’deki yeni özelliklerin çoğunu kullanmıyorum. İstediğim şey, uygulamaları çalıştıracak verimli bir ortam ve güvenlik iyileştirmeleri. macOS’teki Ayarlar uygulaması gibi birçok iyileştirme de pek tatmin edici değil
Tasarım yazılımlarında da aynı. Adobe’nin eklediği yeni özelliklerin çoğunu kullanmıyorum; 10 yıl önceki Illustrator ya da Photoshop ile de gayet mutlu olabilirdim. İstediğim şey daha az şişkin yazılım
Ses ve müzik prodüksiyonunda iş akışı hâlâ geliştiği için yeni özellikler istiyorum, ama verimlilik pahasına değil
Kod editörlerinde VSCode’un özellikleri bana yetiyor. Daha fazlasına ihtiyacım yok; daha iyi LSP isterim ama bu editörün çekirdeği değil. Yine de VSCode’un daha hızlı olmasını ve daha az bellek tüketmesini isterim
Yazılım optimizasyonu da benzer şekilde cazip. Ama mesele “pahalı mühendislik zamanından birkaç saat harcayıp optimize etmek” ile “ucuz RAM’den biraz daha eklemek” arasındaysa daha ucuz seçenek kazanır. Bazen sorun yeterince büyük olur ve optimize etmeye değer
Hangi seçeneğin peşinden gitmeye değeceğine piyasa karar verecek. Donanıma daha fazlasını yığma yaklaşımında azalan getirilere ulaşılınca yazılım optimize edilecek. Moore yasası yavaşlıyor, ama henüz o noktaya gelmemişiz gibi görünüyor
Ama gerçeklik daha çok tersine yakın. Daha ucuz bir fiyat etiketi varsa performansı daha düşük sürümü de tercih ederler
Carmack’e bir karşı çıkıştan ziyade, ara sıra düşündüğüm somut bir örnek var
Electron uygulamaları, tüketici tarafında performans sorunları nedeniyle katlanılan şeylerle nefret edilen şeyler arasında bir yerde duruyor; ama iş yerinde Linux dizüstünü pratik biçimde kullanılabilir kılan tekil yenilik olmaları da oldukça muhtemel. Örneğin kurulum yapmadan MS Teams toplantısına girebilmek gerçekten faydalı
Bu yüzden herkes bugünlerde Winamp gibi sıkı kodlanmış şeyler kalmadı diye yakınıyor, ama baştaki üç harfi unutuyor
Linux’ta da çalıştırılma ihtimali epey var, ama Electron yazılımları hiçbir platformda iyi değil
2010’da temizlikçi olarak çalışırken IT sorumluluğunu da yan iş gibi yapıyordum
O zaman şirkete, son 5 yılın dizüstülerinin, kabaca Nehalem sonrası ürünlerin elektronik tablo işleri için yeterli performansa sahip olduğunu söylemiştim. Yaptıkları iş fiilen bundan ibaretti; 2 çekirdek, 16GB RAM ve 500GB SATA SSD yeterliydi. Pazarlamadaki birkaç kişinin biraz daha güçlü makinelere ihtiyacı vardı ama büyük bir fark değildi; en yeni üst seviye dizüstülerini almayarak çok para tasarruf ettiler
Artık orada çalışmıyorum, ama bugün bile o bilgisayarların elektronik tablolar için gayet yeterli olması gerektiğinden eminim. İş akışları pek değişmedi; değişen şey yazılım. Sürekli güncellendilerse şu anda MS Windows 10 ya da 11’i “çalıştırıp çalıştıramayacaklarını” bile bilmiyorum, ama şişkinlik ve özellikle yalnızca çevrimiçi elektronik tablolar yüzünden üretkenliklerinin ciddi biçimde düşmüş olması muhtemel
Oradaki internet de berbattı. Seçenekler, “iş” diye aylık 300 dolar olan yaklaşık 16Mbit asimetrik DSL ya da aylık 500 dolar olan Comcast 120Mbit kablo bağlantısından ibaretti. 120Mbit bile yalnızca çevrimiçi elektronik tablolar için ancak idare eder; 16Mbit ise kesinlikle yetersiz. Daha kötüsü, internet kesilince işin durması
Diğer yorumun bahsettiği hırsızlığın somut hâli tam da bu ve tamamen katılıyorum. Ofiste elektronik tablo düzenleyip güncelleyen bir dizüstünün internete, saçma derecede yüksek hesaplama/depolama kaynaklarına ya da büyük bant genişliğine ihtiyaç duyması için hiçbir neden yok
Bugünkü bilgisayarların korkunç performansı için, maliyeti müşterilere, yani hem bireylere hem şirketlere yıkmaktan başka bir mazeret yok
https://news.ycombinator.com/item?id=43971960
Dünya zarif, hızlı ve hatasız yazılımlarla değil, işlevler üzerinde dönüyor
Son kullanıcı açısından bir işlevin olmaması ile bug arasında fark yoktur. Performansın kötü olup bir işi tamamlamanın 5 dakika sürmesi ile, işlev olmadığı için kullanıcının aynı işi elle 5 dakika yapmak zorunda kalması arasında da anlamlı bir fark yoktur. İkisi de “yavaş”tır
Son kullanıcı değerini sürekli en üst düzeye çıkarmaya çalışırsanız, kaçınılmaz olarak yavaş ve bug dolu yazılım üretirsiniz. Üstelik kullanıcılara daha hızlı ve daha az bug’lı ama daha az işlevli bir şeyi isteyip istemediklerini sorarsanız, şaşırtıcı biçimde hayır derler. Daha da önemlisi, kurumsal dünyada yazılım satın alan kişi çoğu zaman son kullanıcı değildir; onlar daha fazla işlev, daha az performans ve zarafet ister
İşlev kümesi aynıysa kullanıcılar ve satın almacılar en hızlı, en az bug’lı ve en zarif yazılımı seçer. Ama tek bir işlev bile eksikse kaybedersiniz. Yazılımı hızlı ve zarif tutmanın nedeni, bunu yapmanın işlev eklemeye devam ederken daha az işlevli bir ürüne dönüşmeme olasılığını en çok artırmasıdır
Hızlı ve zarif bir çözüm iyi yorumlar alabilir ve kullanım hissinin iyi olduğu yönünde övgüler toplayabilir. Bu yüzden önemli bir faktör gibi görünebilir. Ama sonuçta yapmak istediği işi yapamıyorsa, kişi onu hiç satın almaz. Gerekli temel işlev varsa, yavaş, sinir bozucu ve bug dolu bir karmaşayı seçer
Microsoft’un artık kullanıcıları tekme tokat, bağıra çağıra bir sonraki Windows sürümüne sürüklemek zorunda kaldığını da hatırlamak gerek. Kararı kullanıcılara bırakmış olsaydı, birçok kişi Windows XP’den sonra yükseltme yapmazdı. Sonraki sürümlerde pek çok güzel yeni özellik olmasına rağmen böyle olurdu
Şirketlerin ve yatırımcıların işlevlerin kendisini istediğine katılıyorum, ama kullanıcılar kesinlikle istemiyor
Mümkün olsa kimse artık hiçbir şeyi yükseltmezdi. Microsoft’un insanları yükseltmek için ne kadar uğraştığına bakmak yeterli. Windows, Office, Slack, Zoom vb. için yeni sürümü istediğini söyleyen birini hiç duymadım
Photoshop gibi her şeyin buluta zorlanmasının nedeni de bu. İnsanların büyük çoğunluğu sunulan yeni özellikleri istemiyor; kurumsal satın almacılar da buna dahil. Geliri korumanın cevabı, özellik sunulup sunulmamasından bağımsız olarak insanlara satın aldırmaktır
Ancak mevcut kullanıcılar zaten yazılımla ihtiyaç duydukları işi yapıyor; bu yüzden yeni özellikler başka yazılımlardan kurtulmalarını sağlayabilir ya da yeni işler yapmalarını mümkün kılabilir. Ama gerçekten olağanüstü önemli yeni bir iş olsaydı, zaten başka bir yazılım bulup kullanmış olurlardı; bu da şimdiye kadar onsuz idare ettikleri anlamına gelir. Bu yüzden mevcut kullanıcı gerçekten düşünceliyse önce performans iyileştirmesi ister, olsa olsa birkaç küçük iyileştirme talep eder diye düşünüyorum
Buna karşılık potansiyel kullanıcılar yazılımı henüz bilmiyordur ya da onu faydalı bulmadan önce başka bir işleve ihtiyaç duyuyordur. Yeni özellikleri makul biçimde arayan kesim onlardır
Dolayısıyla “işlev vs performans” kararı, geliştiricinin önceliğinin yeni kullanıcı eklemek mi yoksa mevcut kullanıcıyı memnun etmek mi olduğunu gösteren bir işarettir. Teknik kişilerin ikincisini tercih etmesi doğaldır. Çünkü bu oyunu zaten oynamışlardır ve edinilme aşamasında değil, gerçekten uzun süre kullanıldıkları zamanda öncelik olmak istediklerini bilirler
Bug’lı ve yavaş ama özellik açısından zengin yazılımların pazara hâkim olmasının nedeni de şirketlerin önce büyümeyi önceliklendirmesidir. Tarih, kullanıcıların özlemle andığı güzel ve zarif yazılımlarla dolu; ama bunlar şirketi sürdürecek kadar yaygınlaşamadı
Ödünleşme iki yönde de gerçektir. Çoğu insan, potansiyel kullanıcı olmaktan çok kullanıcı olarak zaman geçirir. Günümüzde yazılım ve bilgisayarların inanılmaz derecede berbat olduğuna dair yaygın algının büyük bir nedeni muhtemelen budur
Ev ve ofis bilgisayarlarında RAM’e ve daha iyi CPU’lara harcanan para, bunların üzerinde çalışan tüm yazılımların daha ucuz ve daha fazla işleve sahip şekilde piyasaya çıkmasını mümkün kılar