Yazılım pro­je­leri gerçekte neden başa­rı­sız olur

Bir yazılım projesi başarısız olduğunda neden genellikle görünür olanda aranır: yanlış framework, yanlış veritabanı, fazla yavaş kalan bir ekip, vaat ettiğini yerine getirmeyen bir teknoloji. Bu açıklamalar rahattır, çünkü somut bir şeyi işaret ederler. Neredeyse her zaman yanlıştırlar. Teknoloji değiştirilebilir; bir framework değiştirilebilir, bir veritabanı taşınabilir, yavaş bir parça yeniden yazılabilir. Değiştirilemeyen şey, erken sabitlenmiş ve artık her şeyin üzerinde durduğu bir yapıdır.

Bu doküman tek bir tezi savunuyor: Yazılım projeleri nadiren teknoloji yüzünden başarısız olur. Mühendislik kararları, problem anlaşılmadan önce geri dönüşsüz hâle geldiği için başarısız olur. Bu bir proje yönetimi metni ya da süreç tartışması değil — teknik kararların kalitesini ve bunların, büyüyen bir anlayışın onları hâlâ düzeltebileceği şekilde nasıl verileceğini ele alıyor. Bilinçli olarak framework'ten ve üreticiden bağımsız: Başarısızlığın mekaniği her yerde aynıdır.

1. Projeler gerçekte neden başarısız olur

Bir proje, iptal edildiği gün başarısız olmaz. Çok daha önce, kimsenin başarısızlık olarak tanımadığı bir anda başarısız olur: problemin anlaşılması henüz zayıfken sonuçları ağır bir karar verilip sabitlendiğinde. Hasar ancak daha sonra, anlayış büyüdüğünde ve erken kararın yanlış olduğu ortaya çıktığında görünür — ama artık geri alınamaz, çünkü üzerine çok fazla şey inşa edilmiştir.

Özü şudur: Bir projenin başında en az şey bilinir ve en çok karar verilir. Her erken sabitleme, belirsizliğin en büyük olduğu anda yapılır. Bu sabitlemeler geri alınabilir kaldığı sürece sorun yoktur — daha fazlasını öğrendiğinizde düzeltirsiniz. Başarısızlığa dönüşmesi, belirsizlik altında verilmiş erken bir kararın, bilgi yetişmeden önce katılaşmasıyla olur. Teknoloji o zaman yalnızca bu temel hatanın oynandığı sahnedir.

Şema: Sabitleme erkenden yüksektir, anlayış yavaş büyür. Üstteki eğrinin alttakinin önünde olduğu yerde kararlar, değerlendirilebilmelerinden önce geri dönüşsüz hâle gelir.

Avantajlar ve sınırlamalar. Erken aşamada az sayıda kesin karar vermek, bazı belirsizlikleri açık tutmayı gerektirir. Bu yaklaşım yavaş ilerleme gibi görünse de yanlış temele bağlanma riskini azaltır.

Maliyet. Kararları açık tutmak rahatlıktan ödün vermektir: Sabit bir temele güvenemezsiniz ve aynı anda birden fazla olasılıkla plan yapmanız gerekir.

Ne zaman farklı karar veririz. Problemin gerçekten iyi anlaşıldığı ve istikrarlı olduğu yerde — bilinen bir alan, sık inşa edilmiş bir sistem — erken ve kesin karar vermek doğrudur, açıklık ise yalnızca tereddüttür.

2. Bilinmeyen gereksinimler

Başlangıçta kimse gereksinimleri tam olarak bilmez. Kötü analiz yapıldığı için değil, birçok gereksinim ancak bir sistem kullanıldığında görünür hâle geldiği için — gerçek vakalarla, gerçek kullanıcılarla, gerçek istisnalarla temas içinde. Gereksinimler bir kez toplanan bir doküman değil, süreç içinde netleşen bir şeydir.

Bu yüzden iki tür gereksinimi ayırmak gerekir: başlangıçta ortaya konabilenler ve ancak kullanımda görünenler. Birinci tür, inşa etmeden önce titizlikle analiz edilmelidir. İkinci türü öne çekemezsiniz — ne kadar kapsamlı olursa olsun hiçbir analiz, henüz kimsenin yaşamadığını ortaya çıkaramaz. Hata ikinci türü bilmemek değildir; bunu kimse bilemez. Hata, o yokmuş gibi inşa etmektir — mimariyi bugün bilinen yarıya dayandırmak ve öteki yarıya yer bırakmamak.

Asıl sorun gereksinimlerin değişmesi değildir — her zaman değişirler. Sorun, mimari gereksinimler zaten biliniyormuş gibi sabitlendiğinde ortaya çıkar. O zaman varsayımlar gerçekmiş gibi ele alınır ve yapıya dökülür. Bu varsayımlardan biri sonradan değişirse, bir ayrıntının değil, onun üzerinde duran yapının güncellenmesi gerekir. Tam olarak tek bir tahmini gelecek için inşa edilmiş bir sistem, başka her geleceğe karşı kırılgandır.

Avantajlar ve sınırlamalar. Mimariyi yeni ihtiyaçlara açık tutmak, ilk sürümün yalnızca bugünkü duruma göre en dar biçimde tasarlanmaması anlamına gelir. Başlangıçta bir miktar ek esneklik gerekir.

Maliyet. Bilinmeyene açık olmak daha genel, daha temkinli yapılar gerektirir; bunlar o an için, tam olarak ilk durumu karşılayan bir yapıdan daha fazla emek ve düşünce ister.

Ne zaman farklı karar veririz. Bir gereksinim gerçekten sabitse — yasa, sözleşme ya da değiştirilemez bir arayüz nedeniyle — onun üzerine kesin olarak inşa edebilir ve etmelisiniz; değişmez bir şeye karşı açıklık israf olurdu.

3. Mimari borç

Her teknik borç aynı değildir. Bir yerdeki dağınık kod can sıkıcıdır ama yereldir: Geri kalana dokunmadan onu toparlarsınız. Mimari borç başka bir şeydir. Başka kararları kısıtlayan kararlardan oluşur — taşıyıcı hâle gelmiş ve düzeltilmesi sistemin yarısını etkileyen yapısal sabitlemeler. Tam da yerel olmadığı için pahalıdır.

İşin sinsi yanı görünmezliğidir: Mimari borç, onun dayattığı yönde çalıştığınız sürece acıtmaz. Ancak önceki yapıya ters düşen bir şey istediğinizde kendini gösterir — ve o zaman küçük bir kalem değil, görünüşte basit bir değişikliğin neden aylar sürdüğünün açıklamasıdır. Başarısız olan birçok proje, uzun süre görünmeden biriken bu hesap yüzünden çökmüştür.

Avantajlar ve sınırlamalar. Mimari borcu azaltmak için sınırlar ve sorumluluklar erkenden düşünülmelidir. Bu emeğin faydası çoğu zaman yeni bir gereksinim geldiğinde görünür.

Maliyet. Temiz sınırlar ve geri alınabilir yapılar başta zaman ve disiplin gerektirir ve ilk çeyrekte faydasız bir üst yapı gibi görünür.

Ne zaman farklı karar veririz. Kısa ömürlü ya da dar kapsamlı bir sistem için mimari borç bilinçli olarak kabul edilir; orada yeniden yapılandırılabilirliğe yatırım, önlediği zarardan daha pahalıdır.

4. Karmaşıklık sessizce büyür

Hiçbir tek adım bir sistemi yönetilemez hâle getirmez. Bir alan daha, bir özel işlem, ek bir bağımlılık, önemli bir durum için bir istisna — her biri tek başına küçük ve gerekçelidir. Karmaşıklık büyük bir kararla değil, hiçbiri sözü edilmeye değer görünmeyen birçok küçük kararın toplamıyla oluşur. Birinin durup düşüneceği eşiğin altında büyür.

Onu bu kadar tehlikeli kılan da budur: Bir uyarı ışığının yandığı bir an yoktur. Sistem haftadan haftaya yalnızca biraz daha zor anlaşılır hâle gelir ve artış bu kadar küçük olduğu için her basamağa alışılır. Bir noktada kimsenin bütünü kavrayamadığı yere varılır — ama engellenebilecek tek bir adım yoktu. Bunun cevabı karmaşıklığı yasaklamak değil, onu görünür kılmaktır: her eklemeyi toplamda olduğu şey olarak ele almak ve yeteneğin anlaşılabilirlik açısından kalıcı bedeline değip değmediğini sormak.

İşi daha da zorlaştıran, karmaşıklığın neredeyse yalnızca tek bir yönde ilerlemesidir. Bir şey eklemek kolaydır ve sürekli olur; bir şeyi yeniden kaldırmak zordur, çünkü artık kimsenin ona ihtiyaç duymadığını kanıtlamanız gerekir — ve bu kanıtı nadiren biri ortaya koyar. Böylece her ekleme bir mandal gibi çalışır: Yerine oturur ve neredeyse hiç geri gitmez. Bunu bilen, çıkış kapısı genellikle kapalı kaldığı için girişte daha sıkı denetim yapar.

Avantajlar ve sınırlamalar. Karmaşıklığı azaltmak, bazı özel durumlara yönelik kolay çözümleri reddetmeyi gerektirebilir. Karşılığında sistemin bütünü anlaşılır kalır.

Maliyet. Küçük eklemeleri sürekli geri çevirmek gündelik işte sürtünme ve açıklama yükü getirir ve görünür ilerlemeyi yavaşlattığı için kısa vadede sevilmeyen bir tutumdur.

Ne zaman farklı karar veririz. Bir özel işlemin gerçek, sık karşılaşılan bir durumu karşıladığı ve alternatifin kullanıcılara hissedilir bir yük getirdiği yerde karmaşıklık bilinçli olarak kabul edilir — o zaman başıboş bir büyüme değil, gerekçeli bir yatırımdır.

5. Yanlış teşvikler

Kararlar boşlukta değil, teşvikler altında oluşur — ve yazılım geliştirmedeki birçok teşvik, kimse kötü niyetle hareket etmese de yanlış yönü gösterir. En güçlüsü görünürlüğün ödüllendirilmesidir: Gösterilebilen sayılır; kaçınılan görünmez kalır. Erken verilmiş kesin bir karar ilerleme gibi görünür; bilinçli olarak açık tutulan bir karar ise kararsızlık gibi. Böylece riskli olan ödüllendirilir, temkinli olan şüpheyle karşılanır.

İkinci teşvik, bitmiş görünme baskısıdır. “Bitmiş görünüyor”, “değiştirilebilir”i yener, çünkü birincisi hemen görünür, ikincisi ise kendini ancak gelecekte kanıtlar. Bu teşvik altında olan, bugün sonuç gibi görünen kestirmeyi seçer ve yarattığı geri dönüşsüzlüğü, sorumluluğunu başka birinin taşıyacağı bir geleceğe iter. Bu ahlaki bir başarısızlık değil, görüneni ödüllendirip kaçınılanı göz ardı etmenin öngörülebilir sonucudur. Karşı önlem kararın kendi düzeyindedir: Geri alınabilirlik tereddüt olarak değil, bir değer olarak kabul edilmelidir — aksi hâlde her rasyonel paydaş tam olarak yanlış şeyi optimize eder.

Avantajlar ve sınırlamalar. Geri alınabilirliği önceliklendirmek, kısa vadede daha az görünür ilerleme yaratabilir. Karşılığında erken hatalar daha düşük maliyetle düzeltilebilir.

Maliyet. Görüneni daha düşük, kaçınılanı daha yüksek değerlendirmek rahatsız edicidir, çünkü fayda ancak sonra görünür ve o an etkisizlik gibi algılanır.

Ne zaman farklı karar veririz. Kesin ve ertelenemez bir son tarih altında bilinçli olarak geri dönüşsüz bir kestirme seçmek doğru olabilir — oluşan borç saklanmak yerine adlandırıldığı ve daha sonra kapatılması için bir plan olduğu sürece.

6. Geri alınabilirlik

Başarısızlığa karşı temel kaldıraç buradadır. Kararlar aynı değildir: Bazıları iki yönde de geçilebilen kapılardır — yanlış verirseniz geri dönersiniz. Diğerleri arkanızdan kapanan kapılardır — bir kez geçtiniz mi, kolay bir dönüş yolu yoktur. Ustalık, iki türü ayırt etmek ve farklı ele almaktır.

Şema: Geri alınabilir kararlar erken ve hızlı verilir; geri dönüşsüz olanlar ise sorumlulukla geciktirilebileceği kadar geç — anlayışın en büyük olduğu anda.

Buradan çıkan kural basit ve etkilidir: Geri alınabilir kararlar erken ve fazla tereddüt etmeden verilir, çünkü hataları ucuzdur. Geri dönüşsüz kararlar sorumlulukla geciktirilebileceği kadar ertelenir — verilmesi gereken son ana kadar —, çünkü o zamana kadar anlayışın büyük kısmı yetişmiş olur. Ve bir kararın gereksiz yere geri dönüşsüz olacağı yerde, onu geri alınabilir kılan bir biçim aktif olarak aranır: bir sınır çekmek, bir soyutlama eklemek, bir sabitlemeyi değiştirilebilir bir katmanın arkasına gizlemek. Geri alınabilirlik, başlangıçta az şey bilinmesine karşı bir sigortadır.

Avantajlar ve sınırlamalar. Bir seçeneği ileride değiştirebilmek için ek sınır veya soyutlama gerekebilir. Bu yapı, gelecekteki faydasına göre ölçülü tutulmalıdır.

Maliyet. Bu sigorta bedava değildir: Çekilen bazı sınırlara hiç ihtiyaç duyulmaz ve karşılığını vermeyen bir esneklik için ödeme yapılmış olur.

Ne zaman farklı karar veririz. Bir karar yüksek kesinlikle doğruysa ve geri alınması son derece düşük bir ihtimalse sigorta eklenmez; gerçekleşmeyecek bir duruma karşı çekilen sınır kendisi yalnızca karmaşıklıktır.

7. Karar kalitesi

Bütün bunlardan, iyi bir teknik kararın ne olduğuna dair farklı bir anlayış çıkar. Kalite haklı çıkmak demek değildir — başlangıçta bunu kimse güvenilir biçimde yapamaz. Kalite, bir kararın geri dönüşsüzlüğünü gerçekte sahip olduğunuz kesinliğe göre ayarlamaktır. Kesinlik yüksekse sabitleyebilirsiniz. Düşükse seçenekleri koruyan seçeneği seçersiniz: ertelemek, geri alınabilir inşa etmek, daha küçük ve geri çekilebilir olanı daha büyük ve kesin olana tercih etmek.

Buna kararları bilinçli ve izlenebilir biçimde vermek de dâhildir: neyi varsaydığınızı, hangi alternatifleri incelediğinizi ve neden böyle karar verdiğinizi kayda geçirmek — bürokrasi olarak değil, sonraki bir düzeltmenin neyin üzerine kurulacağını bilmesi için (bu, karar kayıtlarının amacıdır). İyi bir karar, daha sonra anlaşılabilen ve gerekirse temiz biçimde revize edilebilen karardır. Amaç hiç yanılmamak değildir — amaç hiçbir hatanın tuzağına düşmemektir.

Buradan şans ve beceri hakkında rahatsız edici bir içgörü çıkar. Belirsizlik altında verilmiş ve doğru olduğu ortaya çıkan geri dönüşsüz bir karar iyi bir karar değil, iyi bir şanstı — kazandınız ama yanlış oynadınız. Tersine, yanlış olduğu ortaya çıkan ve ucuza düzeltilen geri alınabilir bir karar, sonuç yanlış olsa da iyi bir karar kalitesidir. Kaliteyi kesinlik ile geri dönüşsüzlük arasındaki orana göre değil de sonuca göre ölçen, yanlış dersi çıkarır: İyi sonuçlanan riskli oyunu ödüllendirir, yalnızca zararsız bir düzeltme gerektiren temkinli oyunu cezalandırır.

Avantajlar ve sınırlamalar. Belirsizlik yüksekken daha az şeyi kesinleştirmek, açık sorularla daha uzun süre çalışmayı gerektirir. Karşılığında yeni bilgi geldiğinde yön değiştirmek kolaylaşır.

Maliyet. Alternatifleri incelemek ve kararları kayda geçirmek o an zamana, proje boyunca disipline mal olur ve hemen görünür bir getirisi yoktur.

Ne zaman farklı karar veririz. Bir kararın küçük ve kolayca geri alınabilir olduğu yerde tartma işinden vazgeçilir ve hızlı karar verilir; bilinçli karar vermenin emeği, sonuçları ağır ve geri alınması zor az sayıdaki duruma ayrılır.

8. Tipik mühendislik hataları

Projelerin teknik olarak başarısız olduğu tekrarlayan örüntüler — neredeyse hepsi aynı hatanın, yeterince anlamadan sabitlemenin türevleridir:

• Gereksinimler ancak kullanımda netleşecek olmasına rağmen, sanki biliniyormuş gibi mimariyi erkenden sabitlemek.
• Varsayımları kesin bilgi sayarak değiştirilmesi zor mimari kararların içine yerleştirmek.
• Geri dönüşsüz bir kararı, sorumlulukla geciktirilebileceği son ana kadar ertelemek yerine ilerleme gibi göründüğü için erken vermek.
• Hataları ucuz olacak geri alınabilir kararları tartışmakta boğmak ve ertelemek — yanlış uçta temkin.
• Onun yönünde çalıştığınız sürece acıtmadığı için mimari borcun birikmesine izin vermek.
• Karmaşıklığın, her biri gerekçeli birçok küçük adımda, kimse bütünü kavrayamayana kadar büyümesine izin vermek.
• Görüneni ödüllendirip kaçınılanı göz ardı etmek; böylece her paydaş rasyonel olarak riskli olanı seçer.
• Teknolojiyi sorun sanmak ve asıl engel yapı olduğu hâlde framework değiştirmek.
• Varsayımları ve alternatifleri kayda geçirmeden karar vermek; böylece sonraki bir düzeltme neyin üzerine kurulacağını bilemez.

9. Karar kontrol listesi

Sonuçları ağır her teknik sabitlemeden önce sırasıyla netleştirilmesi gerekenler:

• Anlayış mı, tahmin mi? Bu karar anlaşılmış bir probleme mi, yoksa hâlâ gerçek kılığına girmiş bir varsayıma mı dayanıyor?
• Tek yönlü mü, iki yönlü kapı mı? Karar geri alınabilir mi? Değilse — şimdi mi verilmesi gerekiyor, yoksa bekleyebilir mi?
• Mümkün olduğunca geç mi? Bu geri dönüşsüz sabitleme, anlayışın en büyük olduğu, sorumlulukla geciktirilebilecek en son anda mı yapılıyor?
• Geri alınabilir kılınabilir mi? Karar bir sınır ya da soyutlamayla geri alınabilir hâle getirilebilir mi — ve bu bedele değer mi?
• Mimari borç? Bu sabitleme gelecekteki kararları yapısal olarak kısıtlıyor mu ve bu kısıt bilinçli olarak mı seçildi?
• Karmaşıklık görünür mü? Anlaşılabilirlik açısından kalıcı bedel adlandırıldı mı — yoksa eşiğin altında mı kayboluyor?
• Teşvik incelendi mi? Burada görünen ödüllendirilip temkinli olan şüpheyle mi karşılanıyor — ve bu karara etki ediyor mu?
• Kayda geçirildi mi? Varsayım, incelenen alternatifler ve gerekçe, sonraki bir düzeltmenin üzerine kurulabileceği şekilde not edildi mi?
• Revize edilebilir mi? Sonraki bir ekip, problem farklı görünürse bu kararı nasıl temiz biçimde geri alacağını bilir mi?

Bu sorulara cevap veremeyen, bir karar vermiyor, geleceğe bir tuzak kuruyordur — ve tuzaklar projelerin başarısız olmasının en yaygın nedenidir.

Sıkça Sorulan Sorular

Projeler yine de sık sık yanlış teknoloji seçimi yüzünden başarısız olmuyor mu? Nadiren seçimin kendisi yüzünden, sık sık geri dönüşsüzlüğü yüzünden. Uygun olmayan bir teknoloji, değiştirilebildiği sürece çözülebilir bir sorundur. Başarısızlığa dönüşmesi, seçimin sisteme o kadar derinden yerleştirilmesiyle olur ki değişiklik sistemin yarısını etkiler. Sorun teknoloji değildi; onunla ilgili kararın geri dönüşsüz kılınmasıydı.

“Mümkün olduğunca geç karar vermek” düpedüz ertelemek demek değil mi? Hayır. Yalnızca geri dönüşsüz kararlar için geçerlidir ve sorumlulukla geciktirilebilecek en son anı kasteder — daha sonrasını değil. Geri alınabilir kararlar ise tam tersine erken ve hızlı verilir. Ertelemek, zamanı gelmiş bir karardan kaçınmaktır; bilinçli olarak geç karar vermek ise geri dönüşsüz bir kararı, en fazla bilgiyle verilebileceği zamana kadar açık tutmaktır.

Tüm kararları geri alınabilir tutmak gerçekçi mi? Hayır ve amaç da bu değil. Bazı kararların geri dönüşsüz olması gerekir ve çekilen her sınırın kendisi de bir maliyettir. Amaç, sonuçları gerçekten ağır, geri alınması zor az sayıdaki kararı tanımak ve tam da bunları mümkün olduğunca uzun süre açık ve mümkün olduğunca bilinçli biçimde ele almaktır — her şeyi açık tutmak değil.

Mimari borç ile normal teknik borç arasındaki fark nedir? Düzeltmenin yeri ve maliyeti. Normal teknik borç yereldir — geri kalana dokunmadan toparladığınız dağınık kod. Mimari borç yapısaldır: Birçok şeyin üzerinde durduğu, düzeltilmesi sistemin yarısını etkileyen erken bir sabitleme. Birincisini toparlarsınız, ikincisini yeniden yapılandırırsınız — çoğu zaman uzun süre boyunca ve küçük adımlarla.

Karmaşıklığın bir soruna dönüştüğü nasıl anlaşılır? Tek bir adımda pek anlaşılmaz, çünkü her adım küçüktür. Kullanışlı bir işaret, artık kimsenin bütünü kafasında tutamaması ve basit değişikliklerin beklenmedik ölçüde uzun sürmesidir. Bu yüzden bir uyarı sinyali beklemek işe yaramaz; her eklemeyi o anda anlaşılabilirlik açısından kalıcı bedeline karşı tartmak gerekir.

Bu yine de bir mühendislik değil, yönetim konusu değil mi? Teşviklerin örgütsel bir yanı vardır, ama kararlar tekniktir ve geri alınabilirlikleri tasarımda belirlenir. Bir sabitlemenin tek yönlü mü iki yönlü kapı mı olduğu, bir sınırın onu revize edilebilir kılıp kılmadığı, karmaşıklığın görünür kalıp kalmadığı — bunlar mühendislik sorularıdır. Bu yüzden konu yalnızca proje yönetiminin değil, mimarinin masasına aittir.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — ömür boyunca asıl ölçütün neden değiştirilebilirlik olduğu.
• Modüler monolit mi, mikroservisler mi? ve ilgili karar — sonuçları ağır, çoğu zaman fazla erken geri dönüşsüz hâle getirilen bir seçim.
• Erken soyutlama neden karmaşıklık yaratır ve Mühendislik Hikâyesi “Bu iş çabucak yapılır.” — problem anlaşılmadan önce sabitleme ve kestirme.
• Bir legacy monoliti modernize etmek — birikmiş mimari borcun küçük, geri alınabilir adımlarla nasıl ödendiği.

Temelinde Batunet Engineering Method yer alır: kararı problemin özelliklerine göre vermek, geri alınabilir inşa etmek, geri dönüşsüz kararları sorumlulukla geciktirilebileceği kadar geç vermek.

Temel mühendislik ilkesi

Bir kararın değeri doğru olmasında değil, büyüyen bir bilgi düzeyini hâlâ kaldırabilmesindedir. Bir projenin başında en az şey bilinir ve en çok karar verilir — bu çelişki ortadan kaldırılamaz ama yumuşatılabilir: geri dönüşsüz olanı geciktirerek, geri alınabilir olanı erken ve serbestçe karara bağlayarak ve her sabitlemeyi, daha bilge bir gelecekteki benliğin hâlâ düzeltebileceği şekilde yaparak. Projeler insanlar yanlış karar verdiği için başarısız olmaz — herkes yanlış karar verir. Yanlış bir karar, yanlış olduğunu göstermesine fırsat kalmadan katılaştığı için başarısız olurlar. İyi mühendislik bunu önleme sanatıdır.

Başlangıçta akıllıca karar veremezsiniz, çünkü başlangıçta akıllı olamazsınız. Yalnızca, karar kesinleşmeden önce akıllanmanıza izin verecek şekilde karar verebilirsiniz.