Aynı Teknoloji Seçimi Startup’ta Ucuz, Scale-up’ta Pahalıdır

McKinley’e göre her şirketin yaklaşık üç yenilik jetonu var. Dan McKinley bunu 2015’te Choose Boring Technology yazısında anlattı. Yeni bir veritabanı ya da dil seçen ekip jetonlarından birini harcar, jetonlar bitince her yeni araç işletme yükünü bir kat daha artırır.

Yazı çoğunlukla startup’lara verilmiş bir öğüt olarak okunuyor. Bence en çok işe yaradığı yer başka. Aynı kararın başka bir ölçekte başka bir fiyatla geldiğini gösteriyor. Teknoloji seçimi bir risk sorusudur ve riskin yapısı şirketin aşamasıyla birlikte yer değiştirir.

Ürün Belirsizken Hız Kazanır, Ürün Oturunca Bakım

Kuruluşun ilk aylarında kimse ürünün kimin işine yarayacağını bilmiyor. Bu aşamada bir çerçeveyi yanlış seçmek birkaç yüz satır kodun çöpe gitmesi demek. Kod tabanı küçük, kullanıcı az, söküp atmanın bedeli birkaç hafta. Asıl pahalı olan, pazarı geç öğrenmek. Bildiğin sıkıcı bir araçla bir hafta erken yayına çıkan ekip, o hafta kadar fazla şey öğrenmiş sayılır.

Ürün oturup ekipler çoğalınca belirsizlik pazardan çekilip organizasyona taşınıyor. Kırk mühendisin, altı ürün ekibinin ve iki yıllık ortak kodun olduğu bir şirkette yeni bir seçim çoğu zaman bir kütüphane, bir izleme düzeni ve bir işe alım planı demek. Bir ekibin seçimi öbür beş ekibin takvimine yazılıyor. Seçimi geri almak artık hafta sonu işi olmaktan çıkıp eski ve yeni sistemin birlikte yaşadığı bir göç dönemine dönüşüyor. Kararı veren kişi aynı kalabilir, bedelini ödeyen kişi sayısı katlanır.

Amazon’un 2015 hissedar mektubunda Jeff Bezos bu farkı iki kapıyla anlatır. Geri dönüşü kolay kararlar ile tek yönlü kapılar. Aynı teknoloji kararı startup’ta ilk gruba, scale-up’ta çoğu zaman ikinciye düşer. Karara bakmadan önce hangi kapıdan geçtiğini sormak gerekiyor.

Beş Risk Aynı Anda Yük Taşır, Ağırlıkları Aşamaya Göre Kayar

Bir seçimin güvenli olup olmadığını tek soruyla ölçemezsin. Riski beş parçaya ayırınca bağlamın neyi değiştirdiği görünür hale geliyor.

Geri dönüş maliyeti ilk sırada. Startup’ta yanlış seçimi üç ayda söküp atabilirsin, bu risk hafif kalır. Scale-up’ta aynı seçimin üstünde onlarca servis ve yıllarca birikmiş veri durur. Göç, çift bakım dönemi ve yeniden öğrenme maliyeti ayrı ayrı hesaba girer.

Ekip ve işe alım riski ters yönde ilerler. Üç kişi aynı yığını biliyorsa yetenek havuzu bir süre önemsizdir, çünkü zaten az kişi alıyorsun. Ayda beş mühendis alması gereken şirkette o teknolojiyi bilen kişi azsa işe alım süresi uzar, uyum süreci de uzar.

Ekosistem riski, tek bir şirketin yol haritasına ya da tek bir açık kaynak bakımcısına yaslanmak demek. Startup bunu çoğunlukla bilerek alır, hazır platform ona haftalar kazandırır. Scale-up’ta aynı platformun fiyat değiştirmesi ya da desteği çekmesi bütçeyi doğrudan etkiler. Bu konuyu bağımlı olduğun yazılımın bir sahibi olduğunu anlattığım yazıda ayrıca işledim.

Performans riski ürünün ne yaptığına bağlı. Startup’ta henüz kimse yüklenmediği için çoğunlukla görünmez. Scale-up’ta açılış süresindeki küçük bir gerileme her gün çok sayıda oturumda tekrar eder ve gelire yansır.

Organizasyon riski en geç fark edilen. Tek ekipte yığın tercihi bir zevk meselesidir. Altı ekip altı ayrı yığın seçerse ortak kütüphane yazılamaz, izleme dağılır, bir ekipten ötekine geçen mühendis baştan öğrenmek zorunda kalır. Bu maliyet kodda görünmez, ekiplerin birbirine yardım edememesinde birikir.

Bu beş başlığı karar toplantısına şu sorularla götürebilirsin:

• Bu aşamada hangi risk ağır basıyor?
• Seçim hangi varsayımlara yaslanıyor? Örneğin “ekip beş kişide kalır” ya da “tek bir bulut sağlayıcı yeter”.
• Hangi varsayım değişirse seçime yeniden bakarız?
• Geri dönmek gerekirse toplam maliyet ne olur?

Segment Mikroservislere Gitti ve Geri Döndü

“X’ten Y’ye geçtik” haberlerinin en bilinen örneklerinden biri Segment’in. Şirket 2018’de mühendislik blogunda Goodbye Microservices başlıklı bir yazı yayımladı. Yazıya göre ekip, müşteri verisinin gönderildiği hedefleri tek tek ayrı servislere bölmüştü, sonra bu servisleri yeniden tek bir serviste topladı. Yayımlanan gerekçe, ortak kütüphanelerde yapılan bir değişikliğin onlarca servise ayrı ayrı yayılmasının ekibi yavaşlatması.

Bunu “mikroservis kötüymüş” diye okumak yanlış olur. Segment ilk bölünmeyi de bir gerekçeyle yapmıştı. Ürün büyüdü, ekip büyüdü, bağlam değişti ve risk okuması güncellendi. İçerideki toplantıyı, bütçe baskısını, hangi ekibin neye itiraz ettiğini yazıdan göremiyoruz. Dışarıdan yalnızca yayımlanan gerekçeyi biliyoruz.

Bir şirketin kodunu yüzlerce mühendis yazıyorsa, ortak bir platformu varsa ve göç için ayrı bir ekip kurabiliyorsa, aynı seçim o ölçekte bambaşka bir risk yapısına oturur. Beş kişilik bir ekipte bunların hiçbiri yok. Gerekçesini bilmediğin kararı kopyalarsan başkasının ölçeğine göre verilmiş bir hükmü kendi ölçeğine taşımış olursun.

Kararın Yazılı Hali Vazgeçme Koşulunu da Taşır

Sorulara verilen cevaplar toplantıda kalırsa birkaç ay içinde unutulur. Karar kaydı için büyük bir süreç gerekmiyor. Michael Nygard’ın 2011’de yazdığı Documenting Architecture Decisions yazısındaki biçim bir sayfaya sığıyor ve beş parçadan oluşuyor: başlık, durum, bağlam, karar ve sonuçlar. Ben buna bir soru daha ekliyorum, çünkü çoğu kayıtta eksik kalan o. Bu seçimi hangi koşulda yeniden ele alırız?

En çok işe yarayan kısım varsayımlar. “Ekip altı kişi ve hepsi bu dili biliyor” bir varsayımdır. Ekip kırk kişiye çıktığında bu cümle sessizce geçersiz olur ve kimse bir şey yazmadığı için kimse fark etmez.

Çıkış kriteri ölçülebilir olmalı. “Performans yetersiz kalırsa” bir kriter sayılmaz, çünkü ne zaman yetersiz kaldığını kimse söyleyemez. “Açılış süresi iki çeyrek üst üste hedefin üstünde kalırsa” ya da “bu alandaki açık pozisyon dört ayı geçerse” bir kriterdir. Bu rakamları ben uydurdum, sen kendi ürününün sınırlarından türetmelisin. Rakam karar anında yazılmalı. Sonradan konan eşik, verilmiş bir kararı savunmaya yarar.

Seçimi değiştirmeye karar verirsen fatura üç kalemden oluşur. Göç, mevcut kodun taşınmasını ve test ile dağıtım hattının yeniden kurulmasını kapsar. Çift bakım dönemi, eski ve yeni sistemin birlikte yaşadığı süredir ve çoğu zaman planlanandan uzun sürer. Öğrenme, ekibin yeni araçta eski hızına dönmesi için geçen zamandır. Bu kalemleri toplamadan karar vermek yarım faturayla karar vermektir. Kalmanın maliyetini de yazmak gerekiyor, yoksa eski seçim varsayılan olarak ucuz görünür.

Her kaydın bir sahibi olmalı. Bir ekip ya da mimari kurul yetmez, adı olan bir kişi gerekir. Sahip, takvimdeki gözden geçirme tarihinde kriterlere bakar ve kayda “geçerli” ya da “yeniden açıldı” yazar. Altı ayda bir bu tarihi takvime koyabilirsin, bir kriter tetiklenirse tarihi beklemeden toplanırsın. Kayıt yeniden açıldığında risk okuması güncellenmiş olur ve bunun izi yazıda kalır.

Vazgeçme koşulu olmayan seçim ya hiç değişmez ya da bir haber başlığıyla değişir. İkincisi daha tehlikeli, çünkü o noktada kararı sen vermiş olmuyorsun, başka bir şirketin sunumu vermiş oluyor.

Bir sonraki “X’ten Y’ye geçtik” yazısını okuduğunda önce kendi karar kaydını aç ve o yazının hangi varsayımına dokunduğuna bak. Kaydın yoksa bugün en kritik tek seçimin için bir sayfalık bir tane aç.