Varsayılan stack'imiz ilgi çekici değil ve bu bir kaza değil, bir karar. PostgreSQL. Sıkıcı bir web framework'ü. Barındırma için yönetilen bir platform. On yıldır bizim dışımızdaki insanlar tarafından herkesin gözü önünde ayıklanmış araçlar.
Gerekçesi aritmetik. Beş kişi, aynı anda beş yabancı teknolojinin maliyetini kaldıramaz. Her yeni araç bir faturayla gelir: hata modlarını okumak, hata mesajlarının aslında ne dediğini öğrenmek, yalnızca gece üçte yük altında ortaya çıkan keskin kenarı keşfetmek. Kanıtlanmış araçlarda o faturayı başkası çoktan ödemiş ve cevapları da yazmıştır. Bir şey aksi bir saatte bozulduğunda, on yıllık bir veritabanı ile umut vadeden bir veritabanı arasındaki fark, çözümün bir aramayla mı yoksa bir öğleden sonra kaynak kodu okuyarak mı bulunacağıdır.
Yenilik bütçesi
Fikir bize ait değil — Dan McKinley'in "Choose Boring Technology" yazısından geliyor — ama biz onu harfiyen uyguluyoruz. Bir ekibin, kendisi için gerçekten yeni olan şeylere harcayabileceği az sayıda jetonu vardır. Bunları veritabanınıza, dağıtım hattınıza ve dil çalışma zamanınıza harcarsanız ürüne ayıracak jetonunuz kalmaz.
Tuzak şu: bu seçimlerin her biri tek başına makul görünür. Yeni veritabanı sizin erişim deseniniz için gerçekten daha hızlıdır. Yeni çalışma zamanının ergonomisi gerçekten daha iyidir. Hiçbiri tek başına yanlış değildir; ama bir araya geldiklerinde, hata yüzeyini ekipten kimsenin kafasında tutamadığı bir sistem çıkar.
Bütçeyi nereye harcıyoruz
Bütçeyi tek bir yere harcıyoruz: sistemin, projenin var olma sebebi olan kısmına. Müşteri bir modelin etrafında bir şey kuruyorsa denenmemiş iş oraya gider; altındaki her şey olaysız olsun diye seçilir.
Bu daha çok hata ayıklayabilmekle ilgili. Yeni bir altyapının üstünde yeni bir ürün mantığı taşımak aynı anda iki deney yürütmektir; bozulduğunda hangisinin bozulduğunu ayırt edemezsiniz. Temeli sıkıcı tutarsanız bir arıza anında bilgi verici olur — neredeyse kesinlikle sizin kurduğunuz kısımdadır, yani anladığınız kısımda.
Devir teslimin nasıl göründüğünü de değiştiriyor. On yıllık kamuya açık geçmişi olan araçlarla kurulmuş bir sistemi, onu hiç görmemiş bir mühendis hâlihazırda var olan dokümantasyonla devralabilir. Bir sistemi müşterinin kendi ekibine teslim ettiğimizde bunun değeri sanılandan büyük — projelerimizin epey bir kısmı böyle bitmek üzere kurgulanıyor.
Sıkıcı seçeneğin kaybettiği yer
Bu, kendi başına bir muhafazakârlık değil ve kuralın bir çıkışı var. Yeni aracı, gerçek bir eşiği geçtiğinde seçiyoruz: sıkıcı seçenek, sistemin ömrü boyunca yenisini öğrenmekten pahalıya patlayacaksa. Böyle oluyor. Bizim başımıza da geldi ve çıkan karar doğruydu.
Uyguladığımız test şu: bu tercihi, üç yıl sonra sistemi sürdürecek kişiye, araç moda olmadan önce de geçerli olan gerekçelerle savunabilir miyiz? Dürüst cevap "denemek istedik" ise, o bir yan proje konusudur; müşterinin üretim sistemi değil.