Karmaşıklığı seviyor muyuz?
Karmaşıklık, yazılım geliştirmedeki temel zorluktur. Bu nedenle, her zaman karmaşıklığı ortadan kaldırmak için çabalamak önemlidir. Sonuçta, her zaman karmaşık değil, basit sorunları çözmeye çalışmalıyız. Ancak bazen karmaşıklığı severiz ve bu, karmaşık sorunları çözülemez hale getirebilir.
Yazılım geliştirme tamamen programlama ile ilgili gibi görünüyor. Herkes on satır yazabilir. Sorun karmaşık sistemlerdir. Bir sistem, tek bir kişinin anlayamayacağı ve daha fazla geliştiremeyeceği kadar büyük olduğunda, modülerleştirme gibi kavramlar çok önemlidir. Modülerleştirme, sistemi bir insanın daha da geliştirebileceği küçük birimlere ayırır. O zaman karmaşıklık çok önemli hale gelir. Ancak böyle bir karmaşıklıkla, bireyler artık projeleri yürütemez, yalnızca ekipler yürütebilir. Bu da organizasyonel zorluklara yol açar.
Conway yasası
Conway yasası bu bağlamda önemlidir. Bir sistemin mimarisinin, sistemi uygulayan organizasyonun iletişim yapılarını yansıttığını belirtir. Yazılımdaki her modül için organizasyonda bir birim vardır ve organizasyon birimleri arasındaki her iletişim ilişkisi için yazılımdaki modüller arasında bir bağımlılık vardır.
Ancak Conway’in 1968 tarihli makalesinde başka bir şey anlatılıyor: eğer bir kuruluş büyük bir sistem geliştirmek istiyorsa, o zaman projeye birçok insanı dahil etmelidir. Büyük bir ekipte iletişim zor olduğu için belirli bir ekip büyüklüğünde bozulur. İletişim ve mimari birbirini etkilediğinden, iletişim eksikliği kaotik mimariye ve daha fazla karmaşıklığa yol açar.
Ancak Conway daha da ileri gidiyor: Elbette mümkünse küçük bir ekibin uygulayabileceği zarif çözümlere odaklanılmalıdır. Ancak Conway, bir menajerin prestijinin ekibin büyüklüğüne ve sorumlu olduğu bütçeye bağlı olduğunu söyledi. Bu nedenle bir yönetici, mümkünse geniş bir ekip ve büyük bir bütçe için çaba gösterecektir.
İlk başta bu bir sorun gibi görünmüyor. Proje aslında daha küçük bir ekiple çözülebiliyorsa, sadece birkaç oturum vardır. Bu paraya mal olur, ancak projeyi veya mimariyi tehlikeye atmaz. Ancak Conway, Parkinson Yasasının geçerli olduğunu söylüyor. Parkinson yasasıyla, bazı yönetimlerin neden daha fazla çalışanı işe aldığı halde neden daha fazla kazanmadığını açıklıyor. Bu yasa, bir görevin tüm çalışanların uygun zamanını tamamen doldurduğunu belirtir. Görev kolay ve hızlı bir şekilde işlenebilse de, kuruluştaki herkese iş sağlanana kadar giderek daha fazla insan buna katılır. Yani bir yazılım projesinde, ihtiyaç olsun ya da olmasın, ekipteki herkes proje üzerinde çalışacaktır. Sonuç olarak, organizasyon büyüyecek, iletişim bozulabilir ve mimari kaotik hale gelecektir.
Conway’in şu anda 50 yaşında olan bulgusu özellikle ilginç çünkü büyük, önemli bir projenin ne zaman kötü tasarlandığını ve ilerlemesinin zor olduğunu açıklayabilir.
Bu makalenin yöneticileri, farkında olmadan karmaşıklığı severler. Mümkün olduğu kadar geniş bir ekip istiyorlar ve bir sorunu çok karmaşık hale getiriyorlar çünkü büyük bir organizasyon mimariyi çökertebilir.
Peki ya yazılım mimarları?
Ancak sadece yöneticiler değil, biz yazılım mimarları da bazen bilinçsizce karmaşıklığa bayılırız. Bu, örneğin, bağlam içi faydaları ve karmaşıklığı yeterince dikkate almadan olay kaynağı, çok katmanlı mimariler veya mikro hizmetler gibi kalıpları kullandığımızda olur.
Teknolojik oyun içgüdüsü de aşırı karmaşıklığa yol açabilir. Ne de olsa hepimiz teknik zorluklar arıyoruz ve özellikle heyecan verici projeler yapmak istiyoruz. Modern yaklaşımlar ve özellikle karmaşık sistemler bu amaç için uygundur. Bazen gerçekte ortaya çıkmayan teknik sorunları bile çözeriz. Bu, gerçek gereksinimlerin gerektirmediği çok genel veya ölçeklenebilir çözümlerle sonuçlanır ve bu nedenle çok fazla karmaşıklık yaratır.
Bir bahane olarak karmaşıklık
Karmaşıklığa tapmanın özellikle apaçık bir örneği, “Bu bizim işimize gelmiyor. Bizim zorluklarımız Amazon’un veya Google’ınkinden çok daha büyük.” Bunu farklı şirketlerdeki insanlardan duydum. Bu tür açıklamalar şaşırtıcı: Amazon veya Google gibi şirketler son derece karmaşık BT sistemleri kullanıyor ve ekonomik başarıları doğrudan bu BT sistemlerine bağlı. En azından bu BT sistemleri nedeniyle dünyanın en değerli şirketleri arasında yer alıyorlar.
İlk bakışta açıklamalar savunma amaçlı olarak yorumlanabilir: Amazon ve Google’ın modern bir organizasyonu ve bulut altyapısı var ancak şirketin çok daha karmaşık ortamında maalesef bunların hiçbiri çalışmıyor. Ama belki de gurur vardır, çünkü sonuçta neredeyse benzeri görülmemiş zorluklarla uğraşıyorsunuz. Öyle ya da böyle, burada da aynı şey geçerli: karmaşıklığın doğal olarak sakıncaları var ama aynı zamanda bulut, sürekli teslimat ya da mikro hizmetler gibi belirli yaklaşımlarla uğraşmak zorunda kalmamanız gibi bir avantajı da var çünkü bu zaten mümkün değil.
Bu nedenle, gerçekten her zaman karmaşıklıktan kaçınıp kaçınmadığımız sorgulanabilir. Sadece tekniklere odaklanmak, projeleri olabildiğince basit ve zarif yapmak, bilinçsizce karmaşıklığa tapıyorsak işe yaramaz. Bu nedenle, bu bilinçsiz mekanizmaları açıklığa kavuşturmak önemlidir. Tabii ki hala çözülmesi gerçekten zor olan birçok karmaşık problem var.
Makalenin önceki bir versiyonuna yaptıkları yorumlar için meslektaşlarım Jens Bendisposto, Jochen Christ, Lutz Hühnken, Michael Vitz ve Benjamin Wolf’a çok teşekkürler.
tl; doktor
Yazılım geliştirme, karmaşıklığı yönetmekle ilgilidir. Karmaşıklıktan hemen kaçınmak en iyisi olacaktır. Ne yazık ki, karmaşıklığa tapınma bazen – bilinçli veya bilinçsiz olarak – gereksiz yere karmaşık sistemlere yol açarak gerçekleşir.
()
Haberin Sonu