Siz Google Değilsiniz (You Are Not Google)
(blog.bradfieldcs.com)Birçok yazılım mühendisi, teknoloji seçimi konusunda rasyonel davranmıyor. Yeni bir teknoloji seçerken, somut bir ihtiyaç ya da net bir problem tanımı olmadan, sadece Google veya Amazon gibi büyük teknoloji şirketleri kullanıyor diye onu benimsiyorlar. Örneğin MapReduce ve Hadoop, büyük ölçekli veri işleme için ortaya çıktı; ancak gerçekte o ölçekte verisi olmayan şirketler bunları benimsediğinde gereksiz I/O maliyetleri ve işlev kaybı yaşayabiliyor. Bu, tam anlamıyla bir "teknoloji tapınması (cargo cult)" olgusu.
Yazı, bu tür eleştirel olmayan taklitlerden kaçınmak için UNPHAT adlı bir kontrol listesi öneriyor:
Understand – Problemi yeterince anlayın.
eNumerate – Farklı adayları listeleyin.
Paper – Teknolojinin dayandığı makaleyi ya da whitepaper'ı okuyun.
Historical context – Geliştirildiği tarihsel bağlama bakın.
Advantages – Artılarını ve eksilerini dengeli biçimde karşılaştırın.
Think – Bu teknolojinin gerçekten probleme uygun olup olmadığını kendiniz düşünün.
Yazıda ayrıca Cassandra, Kafka ve SOA(Service-Oriented Architecture) gibi teknolojilerin, gerçek kullanım senaryolarıyla uyuşmayan durumlarda eleştirel düşünmeden benimsendiğine dair örnekler veriliyor. Örneğin Kafka, saniyede milyonlarca mesaj işleyen LinkedIn için geliştirildi; ama günde yalnızca onlarca işlem yapan küçük şirketlerde de kullanıldığı oluyor.
Yazar ayrıca, Google'ın bile MapReduce'un artık uygun olmadığına karar verdiğinde onu kullanmayı bıraktığını vurguluyor. Sonuçta önemli olan teknoloji değil; sizin çözmeye çalıştığınız problemin ne olduğunu doğru anlamak ve ona uygun teknolojiyi seçmek.
Son olarak yazar, Pólya, Hamming ve Rich Hickey'nin de aynı mesajı tekrar tekrar verdiğini hatırlatıyor; özü ise basit:
“Düşünün. Ve gerçek problemi anlayın.”
15 yorum
Google önerilerinde tesadüfen karşıma çıkıp geldim ama bu yazı fazlasıyla geek bakış açısından yazılmış bir yazı. İş açısından bakıldığında hiç de doğru bir anlatı değil. Neden mi?
Big Tech’in kullandığı büyük araçlar için uzman bulmak kolaydır.
Big Tech’e girmek için bunları öğrenen çok kişi var ve sırf Big Tech seçti diye bunları çalışan da çok. Doğal olarak bu konuda bilgili insan bulmak da kolay, deneyimli ya da uzman kişileri işe almak da daha rahattır. Peki ya ilk kez gördüğünüz bir araçsa? Buna yoğunlaşmış insanlar hiç yok değildir ama böyle kişileri bulmak, Big Tech araçlarının uzmanlarını bulmaktan çok daha zor olacaktır.
Big Tech’in kullandığı büyük araçlar için referans ve kaynak bol olur
Birçok kişinin kullandığı büyük araçlarda, sorun çözmeye yardımcı olacak kaynaklar ve Google arama sonuçları bolca bulunur. Sorunların çoğu büyük ihtimalle başkalarının da yaşadığı türdendir ve basit bir aramayla problemi kolayca tespit edebilirsiniz. Ama ilk kez gördüğünüz bir aracın sorunlarında referans bulmak zordur; bir problem çıkarsa sebebini anlamak için ciddi zaman harcanması çok olasıdır. Bunun hepsi sonuçta para demek. Bu sorun yeni devreye alınmış küçük bir aracın sorunu mu? Yoksa başka taraftaki bir problemi yanlış mı yorumluyorsunuz?
Aslında Big Tech şirketleri bunları değiştirmekte daha rahattır. Çünkü devasa veri işleme ölçekleri nedeniyle, küçük bir I/O kazancı bile onlar için büyük bir kazanca dönüşebilir. Ayrıca sırf Big Tech benimsedi diye bunu öğrenmek isteyen de çok olur. Ancak küçük ve orta ölçekli şirketlerde, görece küçük veri ölçeği yüzünden ufak bir I/O kazancı o kadar da büyük bir fayda sağlamazken, yukarıdaki sorunlar çok daha ciddidir. Küçük ve orta ölçekli şirketlerin benimsediği çözümleri öğrenmek isteyen kişi sayısı da azdır. Bu yüzden KOBİ ölçeğindeki bir işletmeyseniz, bir geek gibi böyle şeyleri tek tek tartmak yerine Big Tech’in araçlarını taklit etmenin daha ekonomik olduğu sonucuna varmanız sık görülen bir durumdur.
Orijinal metni okuyunca bunun 2017’de yazılmış bir yazı olduğunu gördüm.
Aradan 8 yıl geçmiş olmasına rağmen bu içeriğin hâlâ geçerli olması şaşırtıcı.
Yukarıdaki içeriğe büyük ölçüde katılıyorum!
Ancak küçük ölçekli şirketlerde over-engineering yapılmasının bir nedeni de, büyük şirketleri hedefleyen insanların bu tür araçlarda deneyim kazanmak için küçük şirketlerde bunu yapması olabilir.
Tabii CEO bundan pek hoşlanmaz, haha
Büyük şirketlerin ihtiyaçlarına göre şekillenmiş araçların küçük şirketlerde de aynen kullanılmasının sebebinin büyük kısmı bu değil mi acaba. Bunu kontrol etmesi gereken kişi CTO olmalı ama bazen CTO’nun kendisi bile büyük bir şirkete geçmeyi düşünüyor olabiliyor.
Yapacak pek bir iş yoksa insan gereksiz şeylerle uğraşmaya başlıyor tabii haha
Kolay problemleri bile zorlaştırarak çözmek, sanki bir şey yapmışsın gibi gösteriş yapmaya da yarıyor. Bir de kolay yapınca, gerçekten kolay sanan çok kişi oluyor... hahaha
Bunu küçük yapıp sonra büyütecek şekilde düzeltmekten korktuğumuz için, en baştan büyük yapma durumları oluyor...
Bence bu yazı K8s için de geçerli. “Bakımı zor olacak şekilde kod yazma yöntemleri” kitabını hatırlattı. haha
Sonuçta, teknolojilerin çözmeye çalıştığı problemi ve o teknolojinin ortaya çıktığı bağlamı anlamak gerekiyor. Yazıda verilen örnekler arasında şunlar var:
Bence, onların çözmeye çalıştığı problemle benim çözmeye çalıştığım problemin örtüşüp örtüşmediğine dikkatle bakmak gerekiyor.
Ah, katılıyorum. Üniversite öğrencilerine/junior arkadaşlara mentorluk yaparken onlara teknolojinin tarihini anlamaya çalışmaları yönünde sık sık tavsiye verdiğim günler aklıma geldi.
Teknolojinin bir araç olduğunu, amaç olmadığını bazen unutan çok insan var gibi görünüyor.
Büyük teknoloji şirketlerinde doğrulanmış olması, bu aralar çok kullanılıyor olması... bunlar teknoloji seçiminde başlıca koşul haline geldiği anda gereksiz maliyet artışı da doğal olarak peşinden geliyor.
Kore'de Spring cargo cult'u oldukça güçlüdür.
Spring'de insan bulmak daha kolay olduğu için...
Kore'de Spring, tapınmadan ziyade...
devletin beceriksizliği ile geliştiricilerin üşengeçliğinin bol olduğu bir melez..
Kesinlikle katılıyorum. Sonuçta Spring de problemleri çözmek için kullanılan bir araç, değil mi.
Beyin fırtınası zihin haritası derin öğrenme araştırma zamanı azalıyor, Temmuz bildirimim uzun vadede etkili.