Yazılım asla bitmez

Bazı dersler ancak yıllar içinde öğrenilir, çünkü ancak yıllar içinde kendini gösterirler. Bu da onlardan biri. Bilinçli olarak genel tutuldu — müşteri, proje ve tarih belirtilmeden.

Durum

En uzun süredir devam eden müşteri projesinde bir sistem, görevini uzun bir süre boyunca yerine getirdi. Bu hikâyede dramatik hiçbir şey yok: Sistem çalıştı, ihtiyaç duyuldu, geliştirilmeye devam edildi. Ders tam da bu sıradanlıkta yatıyor — bir olayda değil, sürenin görünür kıldığı şeyde.

Başlangıç varsayımları

Başlangıçta, dile getirilsin ya da getirilmesin, bir son durum fikri vardır: Bir gün sistem bitecek, gereksinimler karşılanmış, iş tamamlanmış olacaktır. Bu fikir nasıl inşa ettiğinizi şekillendirir — sistemi bilinen ihtiyaca mümkün olduğunca tam olarak göre ayarlarsınız. Bitirmek bir hedef gibi görünür.

Sorun

Yıllar içinde son durumun bir kurgu olduğu ortaya çıktı. Gereksinimler değişmeyi bırakmadı — bir şey yanlış planlandığı için değil, sistemin içinde bulunduğu dünya değiştiği için: yeni ihtiyaçlar, yeni koşullar, inşa sırasında kimsenin bilmediği yeni sorular. Sabit bir son durum için inşa edilmiş bir sistem, bu sürekli değişime karşı her yıl biraz daha kırılganlaşır. Bir zamanlar tam oturan şey, sonradan dar gelir.

Neden

Nedenin kendisi son durum varsayımıydı. Bir sistemin bir gün biteceğine inanan, onu bugün bilinen ihtiyaca göre optimize eder ve böylece yarının bilinmeyen ihtiyacına karşı hareketsiz kılar. Hata gereksinimlerin değişmesinde değil — bu olağan durumdur —, bu olağan durum hiç yaşanmayacakmış gibi davranan bir mimaridedir. Bugüne ne kadar tam oturacak biçimde inşa ederseniz, yarın o kadar pahalı olur.

Karar

Çıkarılan ders, son durumu hedef olarak bırakıp yerine başka bir hedef koymaktı: bitmiş bir sistem değil, değiştirilebilir bir sistem. Belirleyici soru artık “bitti mi?” değil, “bir sonraki değişiklik ne kadara mal olur?” — ve mimari, bugünkü duruma ne kadar tam oturduğuyla değil, bununla ölçülür.

Uygulama

Pratikte bu, sistemi değişikliğin ucuz kalacağı şekilde inşa etmek demektir: Bir değişiklik yerel kalsın diye net sınırlar; bir müdahale her yere yayılmasın diye az bağımlılık; iş alanının her şeye dokunmadan uyarlanabilecek biçimde ifade edilmesi. Ölçü, bugüne kusursuz uyum değil, yarına uygun maliyetli uyarlanabilirliktir. Uzun süre boyunca bu, tekrar tekrar karşılığını verdi — gelen her gereksinim, katı biçimde optimize edilmiş bir sistemde olacağından daha az maliyetli oldu.

Avantajlar ve sınırlamalar

Değiştirilebilirlik için inşa etmek, bugünkü ihtiyaca azami uyumun bir kısmından vazgeçmek anlamına gelir. Gelecekteki her değişikliği ucuz tutan bir sistem, o anki tek bir durum için nadiren en zarif olanıdır. Bu bilinçli ödenen bedeldir. Yalnızca ömrünün kısa olacağı öngörülebilen bir sistemde farklı karar verirdik — orada değiştirilebilirliğe yapılan yatırım boşa gider, çünkü hazırlık yaptığınız yarın hiç gelmez.

Ne öğrendik

Yazılım asla bitmez, çünkü dünya bitmez. Gereksinimler sürekli değişir ve bu bir eksiklik değil, yazılımın içinde yaşadığı koşuldur. Buna verilebilecek tek sağlam yanıt, değişikliği ucuz kılan bir mimaridir — hiçbir zaman var olmayacak bir son duruma göre optimize eden bir mimari değil. Uzun ömürlü bir sistemin değeri bugün ne kadar iyi oturduğuyla değil, bir sonraki değişikliğin ne kadar az maliyetli olduğuyla ölçülür.

Bu deneyim Batunet'i nasıl değiştirdi

O zamandan beri bitmiş bir sistem değil, değiştirilebilir bir sistem vaat ediyoruz — ve işimizi bir sonraki gereksinimin ne kadar uygun maliyetle karşılanabildiğiyle ölçüyoruz. Sürekli değişimi bir planın aksaması olarak değil, kendisi için inşa edilen olağan durum olarak ele alıyoruz. Bu, “asla bitmez” ifadesindeki tehdidi ortadan kaldırıyor: Bu projenin bir zayıflığı değil, işin doğasıdır — ve onun için tasarım yapılabilir.

İleri okuma

• Rehber: On yıl sonra da çalışan yazılım — değiştirilebilirliğin neden ömür boyunca asıl ölçü olduğu.
• Rehber: Yazılım projeleri gerçekte neden başarısız olur — anlayış büyüdükçe erken ve katı bağlanmanın neden pahalıya mal olduğu.
• Rehber: Big bang olmadan legacy modernizasyonu — uzun ömürlü bir sistem yıllar boyunca nasıl geliştirilir.
• Karar: Başlangıç noktası olarak modüler monolit — değişiklikleri yerel tutan sınırlar.

Temeli Batunet Engineering Method'tur: bir son durum için değil, değişim için inşa etmek — ve değiştirilebilirliği ölçüt hâline getirmek.

“Bitmiş” yazılımın ulaştığı bir durum değil, bırakılması gereken bir fikirdir. Geriye kalan soru, bir sonraki değişikliğin ne kadara mal olacağıdır.