Bir genç mühendis bana “neden Laravel ile uğraşıyorsun, X yeni framework daha hızlı” diye sorduğunda iç çekerek başlayan bir konuşma açıyorum. Cevap “Laravel daha iyi çünkü Y” değil. Cevap şu: “Her ekip için sınırlı bir karmaşıklık bütçesi var, ben onu daha önemli yerde harcamayı tercih ediyorum."

"Boring” ne demek?

Dan McKinley’nin meşhur “Choose Boring Technology” yazısı bu tabiri popülerleştirdi. “Sıkıcı” burada kötü değil — öngörülebilir, iyi belgelenmiş, hata durumunda Stack Overflow’da on yıl önce verilmiş cevabı bulunabilen anlamına geliyor.

Boring stack benim için şunlar:

  • PHP + Laravel
  • PostgreSQL
  • Redis
  • Nginx + PHP-FPM
  • Linux + systemd + Supervisor

Yeni bir tane ekleyince — diyelim RabbitMQ — onu da boring kategorisine sokmak için 12–18 ay üretimde aktif kullanmam gerekiyor. O zamana kadar deneysel, kuşkulu.

”İnnovation token” kavramı

Aynı yazıda McKinley innovation token diye bir mecaz kullanıyor: her ekibin sınırlı sayıda inovasyon harcayacak token’ı var. Yeni bir dil seçmek bir token. Yeni bir DB seçmek bir token. Yeni bir deployment platformu bir token.

Tipik küçük bir ekip için bütçe: 3 token.

Bunları:

  • Yeni bir programlama dili
  • Yeni bir veritabanı türü
  • Yeni bir mesajlaşma sistemi
  • Yeni bir orchestration platformu

şeklinde harcadığınızda, ürünün kendisine — gerçekten değer üretecek karmaşıklığa — ayıracak token kalmıyor.

Üç token’ımı nerede harcıyorum?

Çoğu projede şu üçünü harcıyorum:

  1. Domain karmaşıklığı. İş kuralları, dağıtık iş akışları, eventual consistency gibi şeyler bütçe yer çünkü iş gerektiriyor.
  2. Yeni bir altyapı parçası (örn. message broker eklemek, search engine eklemek). Yılda en fazla bir kez.
  3. İlginç bir denemenin küçük bir bölümünde — bir özelliği yeni bir araçla yapıp ne öğrendiğimizi görmek için. Çoğu zaman tekrar atılır.

Geri kalan her şey kanıtlanmış.

Birinci dünya sorunu mu?

Hayır. Boring tech savunması özellikle kaynaklarımız sınırlıyken önemli. Büyük şirketler “tüm GraphQL’e taşınıyoruz” derken 200 mühendisin bir kısmı bu işle ilgileniyor. Sizin 3 kişilik ekibinizin bunu yapması = 3 ay özellik geliştirmiyorsunuz.

”Ama bu altyapı eski”

PostgreSQL 1996’dan beri var. PHP 1995’ten. Nginx 2004’ten. Redis 2009’dan.

“Eski” doğru kelime değil — olgun doğru kelime. Olgun yazılım:

  • Edge case’leri keşfedilmiş ve düzeltilmiş.
  • Hata mesajları Google’a yazılınca cevap bulunuyor.
  • Ekibin yeni katılan üyesi ilk gününde productive olabiliyor.
  • “Bu bug’ı kim yaratmış” sorusu kütüphane sürümünüze çıkmıyor.

İstisnaları neredeyim?

  1. Bir özellik kanıtlanmış araçla yapılamıyorsa. Örnek: gerçek zamanlı collaborative editing için CRDT — bu mature olan bir alan değil, sıfırdan yazmak istemezsiniz.
  2. Ekipte herkes yeni araçla deneyimli. Eğer 5 mühendis Go yıllardır yazıyorsa, PHP’ye zorlamak yanlış.
  3. Performans gereksinimi açık ve ölçülmüş. “Daha hızlı olur” hipotezi değil, “şu noktada darboğaz var, X dili çözüyor” demonstrasyonu.

Sonuç

Yeni teknoloji yapmak heyecanlı. Yeni teknoloji çalıştırmak sıkıcı. Bu ikisi arasındaki fark, üretimde 2 yıllık bir ürün ile 6 aylık bir ürünün arasındaki fark. Hangi tarafı önemsiyorsanız ona göre seçim yapın — ama farkı bilerek yapın.

Boring tech bir korkaklık değil, bir bütçe kararı. Bütçenizi daha değerli problemlere ayırın.