DevOps Perspektifinden Teknik Borç Nasıl Satılır?

Teknik borç yaratmamanın daha iyi olduğu sıklıkla dramatik ve acıklı bir şekilde tartışılıyor. Evet, elbette onsuz daha iyi. Ancak sonuçlar yine de ortadan kaldırılabilir. Teknik borcu, zaman içinde büyük ölçüde müdahale eden tüm değişiklik ve iyileştirmeler, altyapı değişiklikleri ve süreç değişiklikleri, ekip yapılarındaki boşlukları gidermeye yönelik (ürünlerin piyasaya sürülmesi çerçevesinde bilinçli veya bilinçsiz yapılan) değişiklikler olarak adlandırıyorum. Ve bu tür şeyler, üretim ve operasyon departmanlarının sağlam ve kendinden emin bir ekip oyunu olmadan düzeltilemeyeceğinden, bu hikaye doğrudan DevOps'la ilgilidir. Teknik Borç - Kimin? Ama önce sorunun kökenine bakalım: neden teknik borçtan bahsediyorum? Çünkü işletmenin buna zaman ayırmamasına çok kırgınım. Bu kırmızı konu, geliştiriciler ve operasyonlar arasındaki tüm raporları, buluşmaları ve iletişimleri kapsar. Kötü, kötü, berbat bir iş, teknik borçla çalışmaya zaman ayırmaz. Hatta haklı bir soru bile ortaya çıkıyor: "Kaliteye hiç ihtiyaçları yok mu?" İleriye baktığımda şunu söyleyeceğim: "Kimsenin kaliteye ihtiyacı yok." Ancak bu düşüncemi biraz sonra açıklayacağım. Bu durumu analiz etmek için iş dünyasının bize bunu neden yaptığını düşünelim. Bunun cevabını alabilmek için de kimin teknik borcu olduğunu düşünmemiz gerekiyor. Bunun sorumlusu kim? Yıllar süren bir ilişkinin ardından herkese yüzük teklif eden Frodo gibi olduğumuzu fark ettim. "Bu yükü taşımama yardım et!" İşletmelerin teknik borçla ilgilenmemizi istemesini (tam olarak istemesini) bekliyoruz. Ancak iş dünyası ile olan karşılıklı yanlış anlamamızın temel nedeni, onların bunu asla istemeyecek olmalarıdır. Bizim için bu bir mühendislik mücadelesidir, ürün mükemmelliğini geliştirmenin bir yoludur, hatta ürünümüze duyduğumuz gururu artıracak bir mekanizmadır. Ancak iş açısından bu her zaman bir baş belasıdır, üzerinde zaman harcamanız gereken gerekli bir kötülüktür (ya da zorunluluktur). Bir taksiye bindiğinizi ve sürücünün "Araba yıkamada durabilir miyim?" diye sorduğunu hayal edin. Bu durumda işletme bir müşteridir ve geliştiriciler de taksi şoförüdür. İşletme öfkeli: "Nasıl yani?! Ben seyahat süresinin parasını ödüyorum, sen de araba yıkamaya gidiyorsun!" Taksi şoförü buna makul bir şekilde yanıt verir: "Temiz, güzel kokan bir arabaya binmek istemez misiniz?" İşletme cevap veriyor: "Dostum, elbette istiyorum! Ama bunu varsayılan olarak bekliyorum ve sırf bunun uğruna araba yıkamaya uğramaya hazır değilim!" İşletmeler teknik borcu bu şekilde ele alıyor. Bu bir araba yıkamacıya uğrama önerisi gibidir. Temiz veya lüks bir salona sahip olmak için taksi siparişi verirken uygun kategoriyi seçiyorum. Sipariş aşamasında buna yatırım yapmaya hazırım ama araba yıkamaya uğramak değil. Çünkü daha önce de söylediğim gibi kimse kalite istemez. Ancak varsayılan olarak beklenir. Bu bir zorunluluktur. İşletmeler oto yıkamaya gitmemeye razı olamazlar ve işletmeler kendi zamanları pahasına oraya gidemezler. Peki ne yapıyoruz? Bir iş lokomotiftir. Özelliklere, satışa ve müşterilere ihtiyacı var. "İstiyorum" ve "keşke" diyerek teknik borcu bir işletmeye satmak mümkün değildir. Ancak işi başka bir şekilde motive etmek mümkündür. Yolculuğum sırasında, teknik borç "satın almak" için 3 iş motivasyonu kategorisi oluşturdum: "Şişman" kayıtsızlık. Zengin bir yatırımcı olduğunda, CEO tuhaf meraklılardan oluşan geliştirme ekibini karşılayabilir. "Peki, bırakın yapsınlar! Önemli olan ürünü bitirmek, takım ruhu harika, her şey harika ve biz dünyanın en iyi ofisi oluruz" gibi bir şey. Benim görüşüme göre, teknik borç pragmatizm gerektirdiğinden çoğu zaman felakete yol açan harika bir serbest stil. Bunu pragmatik bir şekilde yapmadığımızda, sözde havalı mimariden oluşan bir Leviathan yaratıyoruz. Korku. Bu, teknik borç için en etkili, yaygın ve verimli modellerden biridir. Korkutucu olduğunda burada ne tür bir "istek"ten bahsedebiliriz? Bir müşterinin bir başarısızlık veya hack nedeniyle ayrılması gibi bir şeyin meydana gelmesiyle ilgilidir. Ve bunların hepsi düşük kalite, frenler veya başka bir şeyden kaynaklanıyor. Ancak korkuyla açıkça satış yapmak da kötüdür. Korkuyla yapılan spekülasyon güvene zarar verir. Mümkün olduğunca dikkatli ve dürüst bir şekilde satış yapmalısınız. Güven. Bu, bir işletmenin size teknik borç üzerinde çalışmanız için ihtiyaç duyduğunuz kadar zaman vermesidir. Güven, yalnızca toplam paya dikkatli bir şekilde küçük davrandığınızda ve bu zamanı kullanırken mümkün olduğunca pragmatik olduğunuzda işe yarar ve korunur. Aksi halde güven sarsılır. Üstelik birikme de yapmıyor. Sürekli bir süreç dalgalar halinde ilerler: Güven artar ve sonra kaybolur. Daha sonra deneyimlerimi ve benim ve harika ekibim için neyin işe yaradığını tartışacağım. Teknik Borçlu Tavşan Deliği Ne Kadar Derin? 3 yıl önce yeni şirkete katıldığımda bu teknik borcun ne kadar olduğunu anlamam gerekiyordu. İşletmelerden ve ortaklardan gelenler de dahil olmak üzere talep istatistiklerinden bunun var olduğunu biliyordum. Genel olarak neyle uğraştığımı çözmem gerekiyordu. Bu, teknik borçla çalışmanın normal ve zorunlu bir ilk adımıdır. Bulduğunuz ilk şeyi yapmak için acele etmemelisiniz. Durumu bir bütün olarak analiz etmelisiniz. O zaman gördüklerime dayanarak, temel sorunlardan birinin büyük kod bağlantısı olduğu varsayımına vardım. Artık herkesi bu sürece daha az dahil ediyorum ama o zamanlar uygulama paketimizde vurgulamak istediğimiz katmanları düzeltmek için tüm üretim ekibini topladım. Uygulamamızın en az 80 farklı bileşeni vardı (dağıtımlar, kurulumlar değil). Durumu anladıktan sonra müdahale edilmesi gerekiyordu. Aşama 1. Sanal Ekipler O kadar akıllı davrandım ki, herkesin zamanı varmış gibi davranıp her bileşenin etrafında sanal bir ekip oluşturacağım fikri aklıma geldi. Şöyle görünüyordu: "Arkadaşlar, kim hangi bileşeni üstlenecek? Nasıl geliştirilebileceğine dair önerilerinizi oluşturun." Ancak odaklanmayı sürdürmek için hep birlikte ilk aşamayı optimize etme kriterlerini formüle ettik: Gevşek bağlantı Uygun maliyetli ölçeklenebilirlik Yeni geliştiricilerin kolay bağlantısı (basit ve açık ilkeler: bu bileşende tam olarak ne yapılabilir ve ne yapılamaz, ayrıca herkesin "dokunamayacağı" kodun izolasyonu) Gerektiğinde harici API kullanabilme Önerilen teknoloji yığınının erişilebilirliği Mevcut çözümlerde QuickWin optimizasyonları İzleme ve sorun giderme kolaylığı Denetim + lisans saflık ilkeleri Sürüm oluşturma ve eskime ilkeleri Elbette bu bir odak noktası değil, yazılım geliştirmenin neredeyse tüm yönleri için bir dizi kriterdi. Listenin tamamı tek bir cümleyle değiştirilebilir: "Her şeyi düzelt." Bu aşama hiçbir şeyin olmaması anlamında fiyaskoyla sonuçlandı. Bazı şeyleri uygulamada çok az ilerleme kaydettik çünkü bunları ortak bir birikim yoluyla planlamaya çalışıyordum. Görevler anlaşılmazdı. Elle çalıştırıldılar. Bunun hem benim hem de takım için zor olduğunu, ayrıca çatışma ve tartışmaların sürekli büyüdüğünü hemen fark ettim. Böylece 2. aşamaya geçtim. Aşama 2. Teknik Borç Benimdir 1. aşamada şirketimizin CEO'su ile birikmiş iş kotası uygulamamız konusunda anlaştım. %70'ini iş konularına, %15'ini kusurların giderilmesine ve %15'ini teknik borca harcayacağız. İkincisi, bir önceki aşamada şunu fark ettim ki, eğer herkes bir konudan sorumluysa, o konuda hiç kimse sorumlu değildir. Bu kesinlikle turkuaz bir ifade değil. Ben de bundan hoşlanmıyorum. Ancak tam tersi çok yüksek düzeyde olgunluk ve ekip çalışması gerektirir. Bu yüzden teknik liderlerden oluşan bir sistem kurmaya karar verdim. Ancak ben sadece bir bileşenin teknik lideri olarak bir kişiyi görevlendirmedim. Mümkün olduğunca beklentilerimi ortaya koydum, gelişim yollarını belirledim ve üretimdeki durumdan onları sorumlu tuttum. Bileşeniniz üretimde sorun yaşıyorsa OPS uzmanları uyanık değildir. Durumu çözmeye çalışan sizsiniz. Ve böylece yola çıktık. Teknik liderler (sorumlu olanlar) ve teknik borç için %15'lik bir kota (zaman var) var. Ama sonunda gerçeklik neye benziyordu? Karşılaştığımız ilk şey FinTech'in, uyumun ve görev ayrılığının olmasıydı; yani benim ve geliştirmenin üretime erişimi yok ve tanım gereği buna sahip olamayız. Ama yine de şunu söylüyorum: "Arkadaşlar, üretimdeki durumun sorumlusu sizsiniz!" İnsanlara Günlükleri Verin! İnsanlara sorumluluk verdiğinizde lütfen onlara ellerine bir araç verin. OPS uzmanlarıyla yaptığımız ilk şey de bu oldu; teknisyenlere kendi bileşenlerinin günlüklerini görebilmeleri için günlükler sağladık. Operasyonların ve geliştirmenin birlikte çalıştığı DevOps'a doğru ilk adımımızı atarak gerçekten işbirlikçi bir çaba gösterdik. Kullanım, günlük aktarımını (Kibana vb.) ayarlarken geliştirme, günlüklerin hassas bilgiler (kişisel veriler vb.) içermemesini sağlamak zorundaydı. %5 Şanslı Olarak Değerlendiriliyor... Gerçek şu ki, %15'lik kotaya rağmen her sprint'te bazı iş krizleri ve acil enjeksiyonlar yaşanıyor çünkü "Ortak buna şimdi ihtiyaç duyuyor, yoksa gidecek!" Tabii ki, bu teknik borç ilk önce sprintin dışına itildi - sonuç olarak% 0'lık sprintlerimiz oldu. Yüzde 15’lik sprintler de vardı ama ortalama yüzde 5-8 kadar teknik borcumuz vardı. Bu büyük bir sorundur çünkü programcı uygulama için ne kadar zamana sahip olacağını bilemez. Ben de kendi adıma yorulmadan tüm takımların üzerinde uçurtma uçurarak bu duruma yardımcı olmaya çalıştım. Her sprint için ayrıntılı ölçümler toplamayı öğrendik ve sonunda sprint'e baktım. Sprint hacking, teknik borç kotasının sistematik olarak ihlal edilmesidir. Bir sprintte kotanın karşılanmaması her şeyin kötü olduğu anlamına gelmez. Aslında farklı durumlar var ve esnek olmanız gerekiyor. Ama sistematik olarak tekrarlandığında üretim uzmanlarını bir araya topladım, tartıştım ve kota üzerinde anlaşmaya varıldığı için bunun ne kadar önemli ve kabul edilemez olduğunu anlattım. Süreci o modele taşımak benim günlük işimdi. Ve hareket etti ama artık bu yaklaşımın kendi önemli eksiklikleri olduğuna inanıyorum. Yaklaşımın Sınırlamaları Ürün sahipleri, birikmiş işlerin tamamen kendilerine ait olduğu ve tüm görevlerin kendileri tarafından koordine edildiği gerçeğine alışkındır: "Kota iyidir, ancak bu teknik borç kotasında ekibin ne yapacağına yalnızca biz karar veririz!" Geliştiriciler, yeniden düzenleme, ortak metinleri ortadan kaldırma vb. gibi görevler (güçlü bağlantıyı unutmayın) ortaya attıklarında mantıklı bir tepki aldılar: "Ne?! Hangi standart metin? Neyden bahsediyoruz?!" Sonuç olarak, görevlerin yerini teknik borç olarak adlandırılabilecek ancak satıcıya şartlı olarak faydalı olan görevler aldı. Bu yüzden sert bir tavır alıp şunu söylemek zorunda kaldım: "Teknik borç benim! Ve her sprint için teknik borç kotasına her ürün ekibinin teknik borcuna dahil edileceğini iddia ediyorum." Biz böyle yaşadık. Normal yaşayıp çalışmamıza rağmen güvensizlik daha da güçlendi. Bir şey yaptığımızda ve bunun ne olduğunu kimseye söylemediğimizde ve iş görevlerine zaman harcanmadığında, ne gibi bir sonuç getirdiğimiz herkes için belirsizdir. Teknik borç kotası kullanımına ilişkin istatistikler hızla yükseldiği için büyük projeleri yapamama gerçeğiyle karşı karşıya kaldık. Ayrıca büyük projeler genellikle birden fazla ekip gerektirir. Bu da imkansızdı çünkü her ürün ekibi kendi ürününe odaklanmış ve onun gerçekleriyle yaşıyor. Bunları karmaşık bir konuya bağlamak imkansızdır. Ayrıca hiç kimse sprintlerdeki operasyonları dahil etmedi. Üretim gibi sprint ve birikimleri yoktur. Üretimle ilgili görevlerle dolup taşıyorlar, ancak bu genel planlara dahil edilmedi. Ve geliştirme, üretime aktarılacak küçük teknik borç parçaları dahilinde yapılan bir şeyle geldiğinde, uzun bir süre OPS'nin taleplerinde kalabiliyordu. Çünkü gerçekten vakitleri yoktu, onlara ek görevler yüklenildi ve çalışmaları engellendi. Ancak bu yaklaşımın olumsuz yönlerine rağmen oldukça fazla şey başardık. Bu Yaklaşımla Neler Başardık? İlk olarak, otomatik testlerin kas kütlesini oluşturduk. Tüm CI sürecini büyük ölçüde yeniden tasarlayarak, onu utanmadığımız uygar bir süreç haline getirdik. İkinci olarak spagetti koduyla mücadeleyi birçok bileşende başarıyla hayata geçirdik. Modülerleştirme yaptık ve kalıpları azalttık. Bu görevler korkuyla da olsa işletmeye satılamaz. Ürününüzdeki teknoloji boşlukları bu sorunları içeriyorsa ve bunları gidermeniz gerekiyorsa (eğer varsa, önce bunların yapılması gerekir), bunları satmaya çalışmanıza bile gerek yok. Bu ancak “Teknik borç benimdir” modeliyle, ancak kotayla yapılabilir. Pek çok girişim gördüm ve ilk aşamada bunu kendim farklı şekilde yapmaya çalıştım. İşe yaramadı. Nitekim bu modda çalışmak uzun süre dayanamaz. Bu, CTO ve ekip lideri olarak size güvenen yönetimin size verdiği sınırlı bir yetkidir. Aşama 3. Meşru Proje Ardından, teknik borç üzerinde çalışmaya yönelik "meşru" bir proje olan 3. aşamayı başlattık. Varsayım, kapalı kotadan uzaklaştığımız, ortak bir ürün biriktirme listesi üzerinden planlama yaptığımız (yani ürün sahiplerinin bu projelerin yapılması gerektiğini kabul etmesi) ve temiz bir satışa gittiğimiz yönündeydi. Bunu gerçekleştirmek için 2 şey yaptık: Bu proje çerçevesinde yapmaya başladığımız işlerin kapsamını mümkün olduğu kadar daralttım. Üretimde ne için mücadele edeceğimize dair somut beklentiler oluşturdum. Bu, idealizmin tamamen reddedilmesiydi çünkü görevlerimizin mümkün olduğunca pragmatik, anlaşılır ve iş açısından hizmet açısından faydalı olması gerekiyordu. Önemli bir nokta, her ne kadar bu nadiren mümkün olsa da, teknik borcun iş değerini hesaplamaya çalıştığımıza dair belli bir yanılsamaya kapılmamızdır. Ve eğer hala hesaplanabiliyorsa, o zaman kabus gibi bir teknik borcumuz var demektir! Pozitif değer iş için negatif değerden daha işe yarar. Eğer "Bu müşteri gidecek. Şu kadar para getiriyor" derseniz o gidene kadar bu iş yürümez. Bu bir iş değeri değil. Üstelik risklerle çalışma kültürü hala çok yüksek değil, dolayısıyla mod şöyle: "Onlar ayrılana kadar kayıp yok." Ayrıca iş değerini göstermek de gerekli değildir. Gösterebildiğiniz yerde, ancak teknolojik değeri gösterebilirsiniz, ancak bunun hesaplanması gerekir. Teknik Borç Satma Rehberi Teknik borcun satışına ilişkin bu aşamanın tüm iş akışını burada bulabilirsiniz. Bir Odak Alanı Seçin (Sadece Bir) Bu korku yoluyla satış yapmak olduğundan işinizi gerçekten etkileyen bir alan seçin. Alanlar farklı olabilir: Kullanılabilirlik, yeniden çalışma hızı, A/B testlerinin ve deneylerinin güvenliği ve yeniden çalışmanın maliyeti. Çok sayıda alan ve konu var. Benim durumumda erişilebilirliği seçtim çünkü işin radarındaydı ve hizmetimiz üzerinde bir miktar etkisi vardı. Kendinizi kaptırmamak ve tek bir konu seçmek hayati önem taşıyor. İntegral Analiz Yapın Yıla ait kullanılabilirlik ve olay istatistiklerini analiz ettim ve yıl boyunca meydana gelen tüm durumlara ilişkin tüm otopsileri ayrıntılı olarak analiz ettim. Bundan sonra, teknik olarak mümkün olduğu kadar ama yine de esas olarak ne üzerinde çalışmamız gerektiğine dair üst düzey bir anlayış oluşturdum. Kullanılabilirliğin ilk kuralı, her zaman kullanılabilir olacak bir sistem kurmaya çalışmak değil, bir olay meydana geldiğinde hazır olmaktır. Bunu sağlamamız gerekiyor. Kullanılabilirliğin ikinci sorunu ve temel kuralı, bozulma anlaşmasıdır: Bir gün bir şeyler olması kaçınılmazdır ve belki de sağladığınız bazı işlevlerden vazgeçme pahasına hizmetinizi korumaya hazırlıklı olmalısınız. Bu anlaşmanın program düzeyi de dahil olmak üzere sürdürülmesi gerekmektedir. Üçüncü konu izleme ve gözlemlenebilirlikle ilgilidir. Bu, olay kaynaklarının hızlı lokalizasyonu ve müdahale tespit süresinin hızlı olmasıdır. Çok sayıda hatalı testiniz varsa, izlemenize güvenmeyi bırakmanız gerekecektir. Üretim testlerinizde "5 dakika içinde sönmezse beni arayın" gibi hizmet masası tepkilerine yönelik talimatlar varsa üretim durumunu izlemiyorsunuz demektir. Test mümkün olduğu kadar açık olmalıdır: "Gösteriyor - bu bir yerlerde sorun olduğu anlamına geliyor, hadi gidelim!" Bileşen Bileşen Analizi Yapın Bu amaçla her yön ve bileşen için tam olarak ne yapacağımızı oluşturduk. Hizmet ağını nereye sürükleyeceğimizi, izlemeyi nasıl ve neye dayanarak sarsacağımızı kastediyoruz. Burada %15 civarında listeledik ama aslında programda pek çok iyileştirme var. Hepsini ortaya koyduk ama henüz pazarlanabilir değil. Şimdi çıkıp bunu açıkça göstermek adına bu aşamadaki her proje için aşağıdakileri yaptık. Temel, Niceliksel Göstergeleri Formüle Edin Niceliksel göstergelerden çok korkuyoruz: Geliştiricilerin çalışmalarının kalitesini niceliksel göstergelerde nasıl ölçebiliriz? Niceliksel göstergelere karşı pek çok argümanımız var, ancak bunları doğrudan ele almamalıyız. Değer sadece iş değeri olarak alınmamalıdır. Örneğin "en fazla X yanlış pozitif" şeklinde ifade edilebilirler. Kanarya sürümleri sağlamanın veya garantili yama geri alma yeteneğinin sağlanmasının kritik olduğu belirli bir bileşen kümesini listeleyebilirsiniz. Genel kullanılabilirlik elbette niceliksel bir gösterge olmalıdır. Bu bir zorunluluktur. Projeleri Savunmak Bu pragmatik projeler seti, mümkün olduğu kadar net ölçümler ve elde etmemiz gereken sonuçlarla şöyle dedim: "Arkadaşlar, bir teknik borç kotasına ihtiyacım var. Bu projeleri hızlandırmak için havuzunuza dahil etmenizi istiyorum ki onlar da daha hızlı çalışabilsinler. genel planlamaya iş hedefleriyle birlikte tamamen yasal bir temelde gireceğiz." Duyuldu, yaptık ve işe yaradı. Sanırım baykuş nasıl çizileceğine dair videoya benziyor: "Bir oval ve iki çizgi çiz." Sonunda - sihir - bir baykuş elde edersiniz! Ancak tüm sihir, tüm bu projeyi çivilemeniz ve sonuna kadar götürmeniz gerektiğidir. Sadece bu yönde bazı şeyler yapmak değil, sonuca ulaştırmak. Yani belirtilen niceliksel göstergelere ulaşmak ve bunları göstermek. Bu uçurumun %95'inde atlanamaz. Tamamen atlanması gerekiyor. Yaklaşımın Avantajları Böylece (uçurumun üzerinden) atlamaya başladık. Bunu başarıyla yapıyoruz. Şu anda bu projenin ikinci turundayız. Yani ilk proje havuzunu sürükledik ve ikinci proje havuzu üzerinde anlaştık. Ne değişti? Güveni Artırma Gerçek, ölçülebilir ölçümler gösterirsek, açıklık yoluyla güven güçlü bir şekilde artar. Ama gerçek şu ki, teknik borç satışı korku yoluyla gerçekleşir. Bu adımdan kaçınılamaz. Ancak bundan korkmanıza veya utanmanıza da gerek yok. Önemli olan, farklı aşamalarda (integral analiz, bileşen-bileşen analizi) gösterdiğim gibi, korku hakkında spekülasyon yapmak değil, onu gerçekten analiz etmektir. Büyük Projeler Gerçekleştiriyoruz Bunlar artık meşrulaştırılmış projeler olduğundan, ekipler arasında senkronizasyon yapabiliyor ve gerçekten büyük projeler gerçekleştirebiliyoruz. Bazı projeler sprintten sprinte sırayla yapıldı. Bu proje kapsamında teknoloji ekibi tarafından düzenli olarak (haftada bir kez) takip ediliyoruz ve kimin nerede (hangi aşamada) olduğunu anlıyoruz. Bu bilgiler mümkün olduğu kadar açık ve şeffaftır. Projelerin ilerleyişi ve mevcut durumlar yayınlanır ve ürün sahiplerinin (ve bunu görmek isteyen herkesin) kullanımına sunulur. Projedeki OPS'ciler En önemlisi altyapı ve kullanıma sunma sürecinde yeniden tasarlamamız gereken birçok şey olduğunu fark ettik. OPS'liler bu projeye açıkça dahil edildi. Bana göre, OPS'çiler geliştiricilerle bir bileşenin mimarisini nasıl değiştireceklerini tartışırken ve geliştiriciler OPS'çilerle altyapıyı en iyi nasıl değiştireceklerini tartışırken bu, Kubernetes ve Docker'dan daha DevOps'tur. Neden Hemen Yapmadım? Burada 2. aşamanın sonunda bahsettiğim şeye geri dönüyoruz: Daha önce işe yaramazdı. Çünkü 2. Aşamada yaptıklarımızı (yeniden tasarladığımız spagetti kodu, testlerin geliştirilmesi ve CI süreçlerinin yeniden tasarlanması) ölçülebilir ölçümler açısından işletmeye satmamız imkansız olurdu. Bu durum herhangi bir korkuyla ilişkilendirilmedi ve standart argümanımız olan "Spagetti kodu nedeniyle kodlamaya uzun zaman ayırıyoruz" - sektörde kimse dinlemiyor. Dolayısıyla bu yaklaşımın içinden geçemezdik. Benim bakış açıma göre, eğer bu kadar derin bir altyapı çalışması gerektiren bir teknoloji platformunuz varsa, 2. aşamadan kaçınamazsınız. Bunun için çabalamalısınız, ancak sadece sürekli bir uçurtma gibi uçmaya değil, aynı zamanda işletmenizin güvenini kaybetmemek için bu dükkanı yeterince hızlı kapatmaya da hazır olmalısınız.