Sıkıcı Teknolojiyi Seçin (2015)

• Yeni teknolojileri ölçülü kullanıp kanıtlanmış teknolojileri (boring technology) öncelemek, şirketin uzun vadeli başarısı için daha avantajlıdır
• Her şirketin yaklaşık 3 inovasyon token’ı (innovation tokens) vardır ve NodeJS, MongoDB veya yeni ortaya çıkmış araçlar her seçildiğinde bunlardan biri harcanır
• Kanıtlanmış teknolojilerde yalnızca yetenekler (capabilities) değil, arıza biçimleri (failure modes) de iyi bilinir; bu yüzden yeni teknolojilere özgü bilinmeyen bilinmezler (unknown unknowns) riski daha düşüktür
• Teknoloji seçimi tüm ekip ve organizasyonu etkiler; operasyonel yük ve bilişsel yük nedeniyle, "işe en uygun en iyi araç" yerine birçok sorunda genel olarak yeterince iyi çalışan araçlar daha avantajlıdır
• Dikkatli teknoloji seçimi, mühendislere daha büyük sorunlara odaklanma özgürlüğü verir; teknoloji uğruna teknoloji anlamsızdır

---

Sıkıcılığı Benimseyin (Embrace Boredom)

• Her şirketin yaklaşık 3 inovasyon token’ı (innovation tokens) vardır ve bu arz bir süre sabittir — istikrar ve olgunluk sağlandıkça bir miktar artabilir, ancak insanlar ellerindekini abartma eğilimindedir
• Bir web sitesini NodeJS ile yazmak, MongoDB kullanmak veya çıkışının üzerinden 1 yıldan az geçmiş bir service discovery teknolojisini benimsemek ayrı ayrı 1 inovasyon token’ı tüketir; kendi veritabanınızı yazmak ise büyük bir beladır
  • Bu tercihler bir JavaScript danışmanlık şirketi ya da bir veritabanı şirketi için makul olabilir; ancak çoğu şirketin peşinde olduğu şey global commerce’i yeniden tanımlamak ya da web ödemelerini yeniden icat etmek gibi daha büyük misyonlardır — dikkatini ssh gibi bir alandaki yeniliğe harcamak, başarısızlığa ya da başarının gecikmesine giden kısa yoldur
• "Sıkıcı (boring)", "kötü (bad)" ile aynı şey değildir; hem sıkıcı hem kötü teknolojiler de vardır — sıkıcı ama yeterince iyi örnekler: MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• Sıkıcı teknolojilerin avantajı, yalnızca yeteneklerinin (capabilities) değil, arıza biçimlerinin (failure modes) de iyi anlaşılmış olmasıdır
• Teknoloji seçiminde known unknowns (ör. veritabanı CPU %100’e ulaştığında nasıl davranacağının bilinmemesi) ile unknown unknowns (ör. istatistik kaydının GC duraklamasına yol açacağını hiç öngörmemiş olmak) bir arada bulunur; teknoloji ne kadar yeniyse unknown unknowns’un boyutu da o kadar büyüktür

Küresel Olarak Optimize Edin (Optimize Globally)

• Sıkıcı teknolojileri tercih etmek iyi bir önyargıdır, ama tek değerlendirme ölçütü değildir; teknoloji seçiminin ekip, organizasyon ve tüm sistem üzerinde bir kapsamı (scope) vardır
• Yeni teknoloji eklemenin bir maliyeti vardır — zaten Ruby kullanırken Python da eklerseniz karmaşıklık marjinal faydayı aşar; ama Python vs Scala, MySQL vs Redis tartışmalarında insanlar bu kısıtı unutup "işe en uygun en iyi araç (best tool for the job)" sloganına sarılma eğilimindedir
• İşin özü, iş problemlerini yazılım seçeneklerinin çözüm alanına eşlemektir; seçimlerin hiçbir yükü olmasa her problem için yerel olarak en iyi aracı seçebilirdiniz, ancak gerçekte bu yük vardır
  • Bu yükün başlıcaları operasyonlar (operations) ve daha küçük ölçüde **bilişsel yük (cognitive overhead)**tir — izleme, birim testleri, düzeltme için gereken bilgi, init script’leri gibi şeyler hızla birikir
• "İşe en uygun en iyi araç" düşüncesinin sorunu, hem "en iyi"yi hem de "iş"i dar görüşlü tanımlamasıdır — gerçek iş şirketi ayakta tutmaktır; "en iyi" araç ise olabildiğince çok problemde en az kötü (least worst) noktada duran araçtır
• Bir sistemi istikrarlı biçimde çalışır halde tutmanın uzun vadeli maliyeti, inşa sürecindeki rahatsızlığı fazlasıyla gölgeler; olgun ve üretken geliştiriciler bunu anlar

Bazen Yeni Teknoloji Seçin (Choose New Technology, Sometimes)

• Bu mantığı uç noktaya götürürseniz web sitesini sadece Java ile yapmak zorunda kalırsınız; bu gerçekçi değildir — araç çantanıza yeni araçlar ekleyebilmenin bir yolu olmalıdır
• Yeni bir teknoloji eninde sonunda şirket genelinde etki yaratır; bu yüzden eklenmesi, şirket çapında görünürlük (company-wide visibility) gerektiren bir karardır — "bu, hep birlikte konuştuğumuz bir konu" şeklinde kültürel bir beklenti oluşturmak gerekir
• En çok tavsiye edilen pratik, yeni teknoloji eklemeden eldeki problemi nasıl çözeceğinizi kendinize sormaktır — bu, "problem" diye görülen şeyin aslında birinin sadece o teknolojiyi kullanmak istemesi olup olmadığını ortaya çıkarır; durum buysa hemen durmak gerekir
  • Az sayıda teknoloji tercihiyle bile çok yol alınabilir; gerçek cevap çoğunlukla "yapılamaz" değil, "yapılabilir ama fazla zordur" olur — mevcut kaynaklarla hedefe ulaşılamadığını düşünüyorsanız, muhtemelen yeterince yaratıcı düşünmüyorsunuzdur
• Mevcut yığınla bu problemi çözmenin neden aşırı pahalı ve zor olduğunu açıkça belgelemek yardımcı olur
• Yeni teknoloji seçimi saf bir ekleme olabilir (ör. önbellekleme yoktur ve memcached eklenir) ya da mevcut bir şeyle çakışabilir veya onun yerini alabilir — eğer yer değiştirme söz konusuysa, mevcut işlevlerin migrasyonu konusunda net beklentiler konmalıdır; politika genellikle önerilen takvimle birlikte "migrasyonu taahhüt etme" şeklindedir
  • Amaç, enkazı yönetilebilir seviyede tutmak ve yerel olarak optimize edilmiş çözüm yığınlarının kontrolden çıkmasını önlemektir
• Bu süreç külfetli değildir; doldurulacak birkaç soru ve bunları konuşmak için tek bir toplantı yeterlidir — yeni teknoloji ya da yeni servis bu aşamayı sağ salim geçerse, eklenmesi uygundur

Sadece Yayınlayın (Just Ship)

• Polyglot programming geliştiricilere araç seçimi konusunda tam özgürlük verildiğinde problemlerin daha etkili çözüleceği vaadiyle sunulur; ama bu, en iyi ihtimalle safça bir problem tanımı, en kötü ihtimalle ise senkronize akıl yürütmedir — günlük operasyonel toil geliştiricilerin üzerine çöker
• Mühendislere daha büyük sorular üzerine düşünme özgürlüğünü veren şey, tam da dikkatli teknoloji seçimidir; teknoloji uğruna teknoloji ise yılan yağıdır

Etsy Örneği (Dipnot)

• Etsy ilk dönemde bu sorun yüzünden çok zorlandı — çok sayıda Python programcısı işe aldıktan sonra onlara iş bulmaya çalışırken anlamsız bir ara katman kurdu ve bunu kaldırması yıllar aldı / aynı dönemde 90. persentil arama gecikmesi yaklaşık 2 dakikaydı — Etsy başarısız olmadı ama yıllar boyunca hiçbir şey yayınlayamadığı için başarısı gecikti
• Sıkıcı ama kötü teknolojilerin kesişimine sık sık "enterprise software" denir, ancak bu tam isabetli olmayabilir
• Etsy’nin activity feeds örneği — çoğu şeyi PHP, MySQL, Memcached ve Gearman ile birleştirdiği dönemde uygulandı / Redis gibi araçlarla yapılmasına kıyasla uygulaması çok daha karmaşıktı, ama o yığınla da yeterince kurulabiliyordu
  • Sonraki yıllarda ilgi başka alanlara kayarken activity feeds kullanımı 20 kat arttı; ancak paylaşılan platform sayesinde ayrıca bir değişiklik yapılmadan da sorunsuz çalıştı — bu, teknoloji seçiminde ölçülülüğün uzun vadeli faydasıdır
  • Yine de bu mutlakçılık değildir — memcached tabanlı activity feeds pratik bulundu, ama saf PHP ile faceted search içeren tam metin aramayı uygulamak söz konusu değildi; bu yüzden Etsy Solr kullandı