- Basit yaklaşımların makale değerlendirmelerinde ya da terfi süreçlerinde daha düşük değerlendirilmesinin arkasında karmaşıklık yanlılığı vardır; çünkü karmaşık çıktılar daha fazla emek, ustalık ve yenilik içeriyormuş gibi görünür
- Seçenekleri ve bileşenleri çok olan sistemler esnek görünse de, gerçek işletimde açıklama, test ve sorun giderme zorlaşabilir; hatalar ve verimsizlikler artabilir
- Basit fikirler ve sistemler anlaşılması, kullanılması, geri bildirim alınması ve genişletilmesi açısından daha kolaydır; Instagram, 2012’de satın alındığında 13 kişilik bir ekiple on milyonlarca kullanıcıya hizmet verirken PostgreSQL ve Redis gibi kendini kanıtlamış teknolojileri korudu
- Makine öğreniminde de karmaşık teknikler her zaman üstün değildir; orta ölçekli 45 tablo biçimli veri kümesinde ağaç tabanlı modeller, derin sinir ağlarından daha iyi sonuç verdi ve öneri ile aramada iç çarpım (dot product), neural collaborative filtering’den daha iyi örnekler gösterdi
- Karmaşıklığın kendisini ödüllendirmek gereksiz karmaşıklaştırmayı ve not invented here eğilimini besler; bu yüzden sorun ne kadar karmaşıksa önce basit bir çözümün mümkün olup olmadığına ve karmaşıklığın maliyetinin haklı olup olmadığına bakmak gerekir
Karmaşıklık neden daha çekici görünür?
- Karmaşıklık, emeğin bir sinyali olarak algılanmaya yatkındır
- Zor fikirler ve çok sayıda teknik ayrıntı içeren makaleler, çok zaman ve emek harcanmış gibi görünür
- Çok sayıda bileşen ve özelliğe sahip sistemler, daha küçük sistemlere göre daha fazla özenle üretilmiş çıktılar olarak değerlendirilme eğilimindedir
- Yapmasının zor olduğu izlenimi, doğrudan değer ve kalite sinyali gibi çalışır
- Aynı zamanda ustalığın bir sinyali olarak da yorumlanır
- Çok sayıda hareketli parçaya sahip sistemler, tasarımcının her bir parçayı anlayıp bütünleştirebilecek yetkinliğe sahip olduğu izlenimini verir
- Çok sayıda uzman terimi ve ispat içeren makalelere yaklaşmak zordur, ama bu da konu uzmanlığını gösteriyormuş gibi görünür
- Pratikte neredeyse hiç kullanılmayan algoritma ve veri yapılarının mülakatlarda sorulması da bu sinyalle bağlantılıdır
- Yeniliğin sinyali olarak görülmesi de yaygındır
- Tamamen yeni bir model mimarisi oluşturan makaleler, mevcut ağı değiştiren makalelere göre daha yenilikçi bulunma eğilimindedir
- Sıfırdan yapılmış çok sayıda bileşen içeren sistemler, mevcut parçaları yeniden kullanan sistemlere göre daha özgün görünür
- “Sadece tek bir şey değiştirildi, geri kalanı önceki çalışmalarla aynı” değerlendirmesi, basit fikirlerin değerini düşürebilir
- Özellik sayısı arttıkça daha kapsamlı olduğu yanılsaması doğar
- Hem SQL hem de NoSQL veri depolarını destekleyen ya da hem batch hem de streaming pipeline’larını mümkün kılan sistemler, tüm durumları kapsıyormuş gibi görünür
- Lego blokları ne kadar fazlaysa değişime o kadar iyi uyum sağlayacağı düşünülür
- Bu değerlendirme, basit fikir ve sistemlere kıyasla karmaşık olanı aşırı tercih etmeye götüren complexity bias ile sonuçlanır
Basitliğin gerçek avantaj sağladığı noktalar
- Basit fikirler ve özellikler anlaması ve kullanması daha kolaydır
- Benimsenme olasılığı ve gerçek etkisi artar
- Anlatması ve geri bildirim alması da daha kolaydır
- Karmaşık sistemleri açıklamak ve yönetmek zordur; kullanıcıların neyi nasıl yapması gerektiğini anlaması güçleşir
- Ayarlanacak çok fazla şey olduğunda hata artar, adım sayısı fazla olduğunda da verimsizlik ortaya çıkar
- Basit sistemler kurması ve ölçeklemesi daha kolaydır
- Daha az bileşen, daha kolay uygulama anlamına gelir
- Standartlaşmış, hazır teknolojiler kullanıldığında bunları geliştirecek ve bakımını yapacak kişileri bulmak daha kolay olur
- Kod ve iç etkileşimler azaldığı için anlama ve test yükü de düşer
- Gereksiz yere karmaşık sistemler, inşa için daha fazla zaman ve kaynak harcatarak israfa yol açar
- Instagram örneği, basit teknoloji seçimlerinin avantajını gösterir
- 2012’de satın alındığında Instagram, 13 kişilik bir ekiple on milyonlarca kullanıcıya hizmet veriyordu
- Yeni moda teknolojiler yerine kendini kanıtlamış teknolojileri koruyarak mühendis başına operasyon yükünü düşürdü
- Diğer girişimler moda olan NoSQL veri depolarını benimseyip zorlanırken, Instagram anlaşılması kolay PostgreSQL ve Redis kullandı
Operasyon maliyeti ve bakım yapılabilirlik
- Bir sistemi devreye almak son değil, başlangıçtır
- Çabanın büyük kısmı production’a alındıktan sonra ortaya çıkar
- Operasyonu, sistemi aslen kuran ekipten farklı kişiler üstlenebilir
- Basit sistemler bakım maliyetini düşürüp ömrünü uzatabilir
- Hareketli parça sayısı azaldıkça sistemler daha güvenilir ve onarımı daha kolay olur
- Bozulabilecek parça sayısı azalır
- İç etkileşimler daha az olduğu için tek tek bileşenleri yükseltmek ya da değiştirmek daha kolaydır
- Karmaşık sistemlerde sınırlı büyüklükteki ekiplerin anlaması gereken çok sayıda bileşen bulunduğundan bakım maliyeti artar
- Karşılıklı bağımlı parça sayısı arttıkça sorun çözme de zorlaşır
- Thomas Paine, 『Common Sense』 adlı eserinde “Her şey ne kadar basitse dağılma olasılığı o kadar düşüktür; dağıldığında da onarması o kadar kolaydır” der
Makine öğreniminde de basit tekniklerin geri kalmadığı örnekler
- Daha sofistike teknikler her zaman daha iyi performans vermez
- Tree-based models > deep neural networks: Orta ölçekli 45 tablo biçimli veri kümesinde ağaç tabanlı modeller, derin sinir ağlarından daha iyi
- Greedy algorithms > graph neural networks: Kombinatoryel grafik problemlerinde greedy algoritmalar, graph neural network’lerden daha iyi
- Simple averaging ≥ complex optimizers: Çok görevli öğrenme problemlerinde basit ortalama, karmaşık optimizer’lardan geri değil
- Simple methods > complex methods: 32 makale genelinde tahmin doğruluğunda basit yöntemler, karmaşık yöntemlerden daha iyi
- Dot product > neural collaborative filtering: Öğe önerisi ve aramada iç çarpım, neural collaborative filtering’den daha iyi
Karmaşıklığı ödüllendirmenin doğurduğu sorunlar
- Karmaşıklığı ödüllendirmek, insanlara gereksiz yere karmaşık şeyler üretme teşviki verir
- Basit yöntemler ya da sistemler, kolay görünmeleri nedeniyle daha az değerli bulunabilir
- Ödül almak için sistemi karmaşıklaştırmak, en basit çözümü artık açık bir tercih olmaktan çıkarır
- Karmaşıklık daha fazla karmaşıklık üretir ve sonunda işin yapılamaz hale gelmesine yol açabilir
- not invented here eğilimi de güçlenir
- Var olan bileşenleri yeniden kullanmak zaman ve emek kazandırabilecekken, her şeyi sıfırdan yapma eğilimi doğar
- Bu, zaman ve kaynak israfına ve daha kötü sonuçlara yol açabilir
- Terfi süreçlerinde ve makine öğrenimi makale değerlendirmelerinde de karmaşıklık aşırı vurgulanabilir
- Bryan Liles, basit çözümlerin karmaşık çözümlerden daha kolay uygulanıp ölçeklenebildiğini, ama terfilerin çoğu zaman karmaşık çözümler kuranlara verildiğini belirtir
- Micah Goldblum, ML değerlendirmelerinde yöntemin fazla basit ya da mevcut bileşenlerden kurulmuş olmasının sık eleştirildiğini, oysa basitliğin zayıflık değil güç olduğunu söyler
- Kalman Filters, PageRank, SVM, LSTM, Word2Vec ve Dropout gibi yenilikler de bir zamanlar reddedilmişti
Karmaşıklığı ele almanın daha iyi yolu
- Amaç, karmaşık problemleri mümkün olduğunca basit çözümlerle çözmektir
- Çözümün karmaşıklığına değil, problemin karmaşıklığına odaklanmak gerekir
- Basit çözümler, probleme dair derin içgörü ve daha dolambaçlı, daha maliyetli çözümlerden kaçınma becerisi gösterir
- Bu, Albert Einstein’ın “Her şey olabildiğince basit olmalı, ama bundan daha basit değil” sözüyle de örtüşür
- Her şeyi kapsayan tek bir karmaşık çözüm yerine, birden çok odaklı çözüm düşünülebilir
- Her duruma uyan tek çözüm (one-size-fits-all), beklendiğinden daha az esnek ve daha az yeniden kullanılabilir olabilir
- Birden fazla kullanım senaryosunu ve paydaşı aynı anda desteklemek, daha sıkı bağlı sistemlere ve planlama ile geçişte daha fazla koordinasyon ihtiyacına yol açar
- Tek amaçlı sistemlerin işletilmesi daha kolaydır ve gerektiğinde terk edilmeleri de daha kolaydır
- Karmaşıklık yanlılığını azaltmak için Occam’s razor uygulanabilir
- Bu, en basit çözümün ya da açıklamanın genellikle doğru olduğu ilkesidir
- Basit fikirleri fazla hızlı elememek ve değerlerini haklı göstermek için gereksiz karmaşıklık eklememek gerekir
- Karmaşıklığın maliyetini hesaba katarak “Buna gerçekten değer mi?” diye sormak gerekir
Alışıldık karmaşıklığı yeniden kullanma yönündeki karşıt yanlılık
- “not invented here”in karşı tarafında, mevcut bileşenleri otomatik olarak tercih etme yanlılığı da vardır
- Çünkü bunlar zaten bilinir; kişisel deneyimde daha kolay görünür ve kişinin zamanıyla emeğini azaltır
- Ama mevcut bileşenin kendisi çok karmaşıksa, daha basit yeni bir şey yapmak yerine onu kullanmak daha fazla zaman ve kaynak israfına ve daha kötü sonuçlara neden olabilir
- Basit bir seçenek yoksa sıfırdan yapmak gerekebilir
- Ancak yeni yapılan şeyin gerçekten daha basit olmaması, mevcut kadar karmaşık başka bir nesneye dönüşmesi de mümkündür
- Bazı problemler özünde karmaşıktır ve gerçekte ortadan kaldırılamayan essential complexity taşır
- ORM, kötü bir örnek olarak ele alınır
- ORM’ler sürekli yeniden yapılır ve başta basit görünseler de sonunda karmaşıklıkları patlar
- object/relational impedance mismatch iyi bilinen bir sorundur ve ORM fikrinin kendisi özünde karmaşıktır
- Basit kalmış gibi görünen şey muhtemelen ORM değil, query builder ya da data mapper’dır
- PSR önbellek API’si, ortadan kaldırılabilir karmaşıklığa örnektir
- PSR-6 cache API’sinin ardından daha basit PSR-16 cache API’si geldi
- PSR-16, karmaşıklığı ve kavram sayısını azaltarak API’yi daha küçük ve daha az opinionated hale getirir
- PSR-16 uygulaması için PSR-6 adapter’ı ve ters yöndeki adapter oluşturulabiliyor olması, PSR-16’da kaldırılan karmaşıklığın özsel olmadığını gösterir
- Bazı kütüphaneler ve framework’ler, developer experience adına özsel karmaşıklığın ötesine geçerek büyüyebilir
- Gerçek basitlik; satır sayısı, public method sayısı ve coupling gibi ölçümlerle değerlendirilebilen bir özelliktir
- Bir kütüphanenin birkaç yıl içinde ilk boyutunun 10 katına çıkması ve her 6–12 ayda bir büyük breaking change yayımlaması mümkündür
- Büyümeyen bir kütüphaneyi “ölü” sayıp daha “aktif” paketlere geçme motivasyonu da karmaşıklık yanlılığının belirtisi olabilir
- Yayılan karmaşıklıktan kaçınmak için bazen yeniden yapmak gerekebilir
- Gereksinimler sabit tutulabiliyor ve kapsamın yayılıp büyümesi engellenebiliyorsa, yeni bir uygulama daha basit tercih olabilir
- Her iki yanlılığı da güçlendirmemeye dikkat etmek gerekir
1 yorum
Hacker News yorumları
FAANG’deki bir şirkette, karmaşık problem çözmenin terfi kriteri olarak kullanıldığı bir dönemde çalıştım; ne kadar karmaşık problem çözerseniz seviye, ücret ve statü o kadar artıyordu.
Doğal olarak insanlar çözmeye değer karmaşık problemler aramaya başladı; başka şirketler de o şirketin fikirlerini kopyalayınca, karmaşık çözümlere ihtiyacı olmayan küçük şirketler bile benzer teknoloji yığınlarına sahip olmuş gibi görünüyor.
Bugünlerde otomobil UI’larına, özellikle elektrikli araçlardaki karmaşık ve kullanması zor UI’lara bakınca benzer şeyler düşündüm; hatta bu, ihtiyacımı karşılayacak arabayı almamı engelleyecek kadar ileri gidiyor.
Vardığım sonuç şu: sofistike tüketici ile özenen/aspirasyonel tüketici çok farklı ve aspirasyonel tüketici çok daha fazla.
Bu yüzden sofistike tüketiciden fedakârlık edip aspirasyonel tüketiciye göre tasarlamak ekonomik olarak mantıklı.
Aspirasyonel tüketici, kusurları ve göz boyamayı tüketim başarısının bir simgesi gibi gördüğü için bunlara katlanıyor.
Kaba söylemek gerekirse, “lüks” araba kullanmaktan o kadar hoşlanıyor ki yanında gelen çöpü göremiyor; ben ise onlarca yıldır lüks araba satın alan biri olarak vites kolunun sadece anlaşılır olmasını istiyorum.
Dokunma hedefleri sebepsiz yere fazla küçüldü; geliştiriciler UI’ı sabit bir masadaki ekranda ya da hareket etmeyen bir arabada tasarlayıp test etmiş gibi.
Hareket eden bir arabanın içinde her şey dağılıyor.
Vites kolu, sinyal, silecek ve far kolları olmayan yeni arabalar tam bir karmaşa.
Elinizi dayayacak yer bile olmayan bir ekranda sürücü koltuğunda oturup küçük hedefleri dürterek tutturmanız gerekiyor; dolaylı kontrol, kafa karışıklığı, isabetsizlik ve dikkat dağılması yüzünden herkesin daha kötü araba kullanmasına neden oluyor.
Kilitleme/açma, camları kapatma, ön ısıtma/ön soğutma, sabah işe akşam eve otomatik navigasyon ayarlama, hangi telefon anahtarının kullanıldığına göre koltuk ve ayarları düzenleme gibi zahmetli işleri otomatikleştiriyor.
Ücretsiz bağlantı sayesinde navigasyon da düzgün çalışıyor; daha önce kullandığım araç içi GPS’lerin hepsi işe yaramazdı.
Müzik seçimi ve oynatma ekranı da iyi; sesli komutlar da müzik seçimi için epey iyi çalışıyor.
Mükemmel değil ama şimdiye kadar sürdüğüm tüm içten yanmalı motorlu araçlardan daha iyi olduğunu düşünüyorum.
Sabah işe çıkma süreci kapıyı açmak ve sürüş moduna almak olmak üzere iki adımda bitiyor.
Kışın içten yanmalı bir araçta anahtarı bulmak, arabayı açmak, kapıyı açmak, eşim kullandıktan sonra koltuğu ayarlamak, marş düğmesi, ön camın buğusunu/buzunu çözmek, arka cam rezistansı, ön camdaki buzu kazımak, GPS’te iş yerini seçmek, el frenini indirmek, debriyaj, vitese takmak derken 10’dan fazla adımdı.
Arabaya bizzat sahip olmayan insanlar internette dokunmatik ekrandan sürekli yakınıyor; ama Tesla sahipleri, dokunmatik ekran olsun olmasın diğer arabalardan üstün olduğu için markada kalmaya devam ediyor.
Technology Connections yakın tarihli bir videoda, silecekleri değiştirmek için çirkin 90’lar tarzı bir kolu 4 saniye basılı tutması gerektiğini ve bunu öğrenmek için kullanım kılavuzunu okuması gerektiğini söylemişti.
Ayrı ayrı takılmış parçalardan yapılmış arabalarda bu tür saçma davranışlar çok yaygın.
Buna karşılık benim arabam telefonuma gerçek zamanlı güvenlik kamerası bildirimleri gönderiyor, işe giderken sürüşü üstleniyor ve vites seçimi de genelde emniyet kemerini takıp frene bastığınızda arabanın yönü kendisinin seçmesi seviyesinde.
Önemli işlevlere 50 düğmeyle değil, direksiyon üzerindeki tekerlekle bağlama göre erişilebiliyor.
Basit ama güçlü; sorun, yukarıda bahsedilen lüks arabaların uygulamasının berbat olması.
Theo Browne adlı YouTuber'ı ara sıra izliyorum; kendisi ağırlıklı olarak frontend geliştiricisi
Çözümü anlatışını izleyince kafama beyzbol sopasıyla vurulmuş gibi hissediyorum; demoya giren öğe sayısı göz yaşartacak kadar fazla
Tek bir videoda geçen React'le ilgili anlaşılmaz terimlerin sayısına da şaşırıyorum
Özellikle bir kişiyi hedef gösterip eleştirmek istemiyorum ama bu karmaşıklığın onun popülerliğini korumasını sağlıyor olabileceğinden endişeleniyorum
Buna karşılık Pieter Levels, Suspense, sunucu tarafı rendering, Hydration gibi konulara girmeden düz PHP'yi doğrudan production'a sürüyor
İkisi de sonuçta aynı hedefe ulaşıyor ama Pieter Levels'ın çok daha fazla para kazanacağını düşünüyorum; aradaki karmaşıklık farkı da büyük
Hatta Nomad List gibi şeylerin Theo'da gördüklerimden çok daha zengin özelliklere sahip olduğunu düşünüyorum
Sonra başka birinin onu tanıdığını ve Theo'nun kanalında sert konuştuğu bir konu üzerine dostane ama yüksek sesli bir tartışmaya girdiklerini gördüm
Kişiliği, gereksiz karmaşıklık üzerinden medya etkileşimini en üst düzeye çıkarmaya kusursuz biçimde uygun görünüyordu
Ne kadar karmaşıksa tartışılacak o kadar çok şey oluyor ve anlaşılması güç seçeneklere aşina olmayan insanlara daha zeki görünebiliyor
Oyuncak örneklerde kullanılan kütüphane ve kod miktarı, production'da gördüğümüzden çok daha fazla; ben de epey canavar gibi sistemler görmüş biriyim
Bunun ne kadar süreceğini bilmiyorum
Kullanmayacağınız bir sürü ıvır zıvır içeriyor ve asıl kullanacağınız kısımların önüne geçiyor
Bir sorun çıktığında artık yalnızca programlama dilini ve kendi kodunuzu değil, framework içinde izlediğiniz yol üzerindeki kodu da anlamanız gerekiyor
Bu yol kolayca 10-20 fonksiyon derinliğine inebiliyor ve çeşitli edge case'lerde ne olduğunun yeterince somut biçimde belgelendiği durumlar son derece nadir
Nispeten basit bir şey yapmak için kullanılan araç miktarı inanılmaz ve DevOps'ta da benzer şeylerin yaşandığını hissediyorum
Bu sorun sanki şirketlerdeki “frontend geliştiriciler” tarafından yaratılmış gibi
Full-stack ya da backend geliştiricilerin yaptığı “gerçek mühendisliğe” karşı bir tür aşağılık duygusu, frontend'de de “gerçek mühendislik” sorunları yaratma isteği doğurmuş gibi görünüyor
On yıllarca legacy sistem geliştirdikten sonra, kimi zaman bizim şirketin tasarımıyla, kimi zaman müşteriler için sözleşmeli işlerde, belirli müşterilerin karmaşık ve bol hatalı yazılımları tercih ettiğine beni inandıran çok şey gördüm
Çünkü arkasına saklanabiliyorlar
“Yazılımda bug olduğu için zamanında bitiremedim”, “Yazılım Y'yi desteklemediği için X'i yapamadım”, “köpek ödevimi yedi” gibi
Çoğu durumda basit, kolay ve çok daha az hatalı çözümler tasarlamak mümkündü; ama o zaman kullanıcıların belirli başarısızlıkların yazılım sorunu değil, kendi yetersizlikleri olabileceğini gizlemesi zorlaşırdı
Bu yüzden özellikle yukarıdan baskının yoğun olduğu şirketlerde yöneticiler, tam olarak anlamadıkları ve hataları ile sorunları olduğu bilinen yazılımlarla çalışmayı gerçekten tercih ediyor
27 yaşımda, 5 yıl çalıştığım ilk işimden ayrılırken aşırı karmaşık bir GUI programını iki CLI programını saran küçük bir GUI ile değiştirmiştim
Yanlış girdi verilse bile her seferinde çalışıyordu; nadiren başarısız olduğunda da faydalı hata mesajları veriyordu
Onu kullanan üç kadın benden gerçekten nefret ediyordu
Şirketten ayrıldıktan yaklaşık bir yıl sonra nedenini anladım; o zamanlar pek akıllı değildim
Zamanla insanların Microsoft Teams gibi şeyler istediğini düşünmeye başladım; çünkü gerektiğinde onunla kendilerini kurtarabiliyorlar
Fiziksel UI'da bizim grup buna mikrodalga fırın problemi diyor
Mikrodalga fırındaki 20 ek düğmeyi kimse kullanmıyor ve çoğu kişi yalnızca bir iki düğmeyi kullanıyor; ama daha az düğmeli mikrodalga fırını da kimse satın almıyor
10 yıldır Samsung ME82V'yi seviyorum; iki kadran yetiyor
Bu yüzden gece 2'de gizli atıştırmalık işi, 1999'daki gibi mikrodalgayı gözlemekten ibaret oluyor
İstediğim tek şey hız kadranı, anlık çalıştırma düğmesi ve güç düğmesi; herkes de bunu istiyor ama nedense her nesilde kimsenin kullanmadığı bir sürü özellik ekleniyor
Her zaman aynı iki düğmeyi kullanmak zorunda değilsiniz; başka düğmeleri kullanabilme seçeneğini seviyorum
Ayrıca düğme sayısı fazla olduğunda çoğu zaman daha iyi teknik özellikler de beraberinde geliyor
Daha az kontrol ve daha az özellik vardı ama kullanıcı deneyimi harikaydı
Özellikleri aşırı fazla ve karmaşık rakip ürünlerle karşılaştırınca iPod'un sadeliği aklımda kalmış
Bu tür yakınmalar, basmakalıp özdeyişlerle dolu olduğu için sinir bozucu
Einstein ve Dijkstra’dan alıntı yapınca zeki görünmek kolay; sonradan bilmenin avantajıyla ve gerçek gereksinimlere dair cehaletle karmaşık çözümleri genellemek ve parmakla göstermek de kolay
“Mümkün olduğunca basit, ama daha basit değil” her zaman doğru bir söz
Çözüm dağınıksa daha basit yapılmalıydı; ilkel bir çözüm sorun çıkarıyorsa fazla basit yapılmamalıydı
Sanki neden baştan mükemmel yapmayı düşünmedin, der gibi
Gerçekte, bir çözümde birden fazla ödünleşim olduğunda neyin basit olduğu konusunda uzlaşmak bile çok zor
Karmaşık tek bir veritabanını sürdürmek, üç “basit” veritabanı tutup yönetim işini üçe katlamaktan ve sonunda senkronizasyon ya da dağıtık transaction uygulamaktan daha kolay olabilir
Şimdi uygulaması kolay olan şey ileride karmaşık sorunlar yaratabilir; sorunu tamamen çözmeyen hazır çözümler, desteklenmeyen durumlar için karmaşık geçici çözümler doğurur ve en sonunda uygun bir şeye geçişin karmaşıklığını da ekler
“Sadece basit yap” tavsiyesi çoğu zaman bu tür çözümlerin her derde deva olmadığını ve karmaşıklık ile basitlik arasında net seçeneklerin nadir olduğu gerçeğini bilmez
Projelerde mevcut dağınık sistemler, tutarsız yasal gereklilikler, değişen iş gereksinimleri gibi kısıtlar vardır; ayrıca pazara çıkış hızı ya da işe alınabilecek yetkinlikleri öncelemek gerekebilir
Ekonomi de acımasızdır: yıllık rapor üretme süreci bir Rube Goldberg makinesi gibi olsa bile yılda yalnızca bir kez kullanılıyorsa, yeniden yazılsa maliyeti 50 yıl içinde bile çıkmayabilir
Karmaşıklık tartışmaları, projelerin ve gereksinimlerin büyüdüğü gerçeğini neredeyse hiç kabul etmez
Bugün kusursuz derecede basit olan şey, ileride beceriksizlik ya da kötü niyet yüzünden değil, tamamen rasyonel bir şekilde karmaşıklaşabilir
Başta veriyi düz metin dosyalarında saklamak zarif biçimde basittir, ama daha sonra berbat bir NIH veritabanına dönüşebilir
Öte yandan üç satır veri için baştan veritabanı kullanmak da aşırı tasarımdır
Refaktör etmenin maliyeti vardır; bu yüzden her zaman ideal çözümü kullanmak da o kadar basit değildir
Gerçekte bariz olan şeyler sandığımızdan çok daha az
“Mümkün olduğunca basit, ama daha basit değil” sözünü mükemmellik talebi gibi yorumlamak mantıksal olarak buraya varmaz
Pratikte iterasyonun planı yendiğini biliriz
Neyin basit olduğu konusunda uzlaşmak zorsa izin istemek yerine af dilersin
Bu sektörde, belki başka birçok sektörde de geçerli olan kural bu
Hayalcilerde ve frontend geliştiricilerde görülen belirli bir tür arızi karmaşıklık kesinlikle var
Karmaşıklık karmaşıklıktır
Daha karmaşık sistemlerin eğitimler, videolar gibi çevresel materyaller üretmesi gibi ikincil bir etkisi de var
Ayrıca bunları öğrenen insanlar, şirkette ihtiyaç duyulan beceri ve sorumluluklara sahip hale geldiği için, sadece düzgün çalışıp böyle insanlara ihtiyaç bırakmayan bir şeye kıyasla iş güvencesi sağlar
Yazılımlar basit ve sadece çalışır şekilde yapılmış olsaydı IT’de var olmayacak çok fazla iş var
Basit durumlarda “sadece çalışır”, ama içini kurcalamaya ya da önemsiz olmayan bir iş yapmaya kalkmazsan sorun yok
Benzetme epey isabetli olabilir
Konu makale hakemliğiyse, bir hakem olarak makalelerde aradığım şey basitlik de karmaşıklık da değil; “yenilik” de değil
Aradığım şey, problem hakkında titiz ve düşündürücü bir ampirik analiz
Gönderiler arasında sıkça şunlar oluyor: 1) mevcut bir düzine fikri birbirine dikmiş Frankenstein benzeri bir sistem önerip, her parçanın başarısızlık biçimlerini derinlemesine analiz etmeden eldeki en yeni oyuncakları mümkün olduğunca kullanarak “kalın yazılacak sayılar” elde etmeyi başaranlar; 2) mevcut bir yöntemi basitçe biraz değiştirince tesadüfen performansı artan, ama bunun neden işe yaradığına dair uygun ampirik ya da teorik gerekçesi olmayanlar
İkinci türün topluluk ya da okuyucu için çok az da olsa değeri olabilir, ama çoğunlukla işe yaramaz olduğunu düşünüyorum
Okuyucu için değerli olan, bir doktora öğrencisinin probleme uzun süre baktıktan sonra sezgisini nicel ve doğrulanabilir bir teyide bağlaması ve öngörü gücü olan yeniden üretilebilir gözlemler elde etmesidir
Örneğin “bu makalede açıklanan Z mekanizması yoluyla X’in Y’yi etkilediğini tüm durumlarda deneysel olarak doğruladık; bu yüzden A metriğini B% iyileştirdik ve bu Z ile tutarlı” gibi
Karmaşıklıktan bağımsız olarak “X yaptık, A B% arttı” tarzı yetersizdir
Ne yazık ki tüm hakemler buna katılmıyor
Lisedeki tarih öğretmenim, İkinci Dünya Savaşı’na giden olaylar hakkında bir deneme yazmamızı istemişti
İlk soru uzunluğun ne kadar olması gerektiğiydi; öğretmen, bu karmaşık konuyu bir A4 sayfasında ele alabilirsek tam puan vereceğini, ama bu kadar kısa bir yazıyla ele alınabileceğinden içtenlikle kuşku duyduğunu söylemişti
Herkes bu mantık karşısında şaşkına dönmüştü
Öğretmenin böyle bir şey söylediğini kimse daha önce duymamıştı; bu da küçük yaştan itibaren daha fazlasının her zaman daha iyi olduğu öğretisini aldığımızı gösteriyor
Bir açıklama, seçilen soyutlama düzeyine göre her zaman uzun ya da kısa yapılabilir; insanlar da genellikle bu düzeyi bağlama ve toplumsal teamüllere göre seçer
Örneğin “bir tuş vuruşu ekrandaki harfe nasıl dönüşür” bir cümleyle de açıklanabilir; firmware, yazılım yığını, elektronik, malzeme bilimi ve üretim süreçlerine girilirse birkaç uzun kitapla da açıklanabilir
İkinci Dünya Savaşı da Hitler’in Poland ve France’ı işgaliyle başladı denebilir; Versailles Antlaşması’na gidilebilir, hatta Dünya’daki yaşamın evrimine kadar uzanılabilir
Sonuncusu ukalalık olur, ama teknik olarak İkinci Dünya Savaşı’na giden bir olaydır
Rich Hickey’nin Simple Made Easy konuşmasını şiddetle tavsiye ederim
Karmaşıklık hiç de iyi satmaz, ama kolay olan iyi satar
Bir şirket ‘foo’ kullanmayı bilen çok sayıda kişiyi işe alabiliyorsa ve sektör sürekli ‘foo’dan bahsediyorsa, foo tam bir keşmekeş olsa bile onu seçecektir
Lambda mimarisi, Apache projelerinin çoğu, container’lar vb. buna örnek