Tag Archives: Analysis Paralysis

Anti-Pattern: Analysis Paralysis

Gün geçmesin ki bir tane daha anti-pattern öğrenelim, işlerimizi düzene sokalım. Belki de alemlerin en çok dile getirilen fakat buna oranla anlamı tam olarak bilinmeyen anti-patternine de bakalım istiyorum. Bu seferki kalıplaşmış bir AP1, ne olduğu da adından belli. Plaza çalışanlarının ağzında sakız olmuş, bunu bileyeni PM2 yapmıyorlar o derece. Nerede bir sorun varsa bu anti-pattern’i belirtmekte ve aslında hayatın anlamı analysis paralysis, o derece. Peki gerçekten bu terimi doğru kullanabiliyor muyuz. Gerçekten bir anti-pattern olarak görebiliyor muyuz? Bunu irdeleyelim istiyorum.

Anti-Pattern nedir?

Her AP anlattığımda bu kısmı yazmadan geçmek istesem de elimde değil. Kavramı defalarca dile getirerek aşina olabiliriz. AP ya da Anti Pattern dediğimiz şey, toplumsal deneyimlerin birleşimidir. Bir yazılım sürecinde, bir hata ya da yanlış uygulama var ise ve insanlar bu hataya sık sık düşüyorsa kalıplaştırılır ve bir anti-pattern oluşur. Anti pattern dediğimiz aslında yaptığımız ve yapmamamız gereken işleri temsil eder. Yanlışlarımızı gösterir, kurtulmanın yollarını belirtir.

Analysis Paralysis Nedir?

Project Management kategorisinde bulunmakta olan bir AP’dir. Kısa tanımını direk vermek istiyorum bu AP’nin.

Projenin verilmiş olduğu akıllı ve iyi donanımlı analist arkadaşların ya da yazılım takımının analiz sürecine başlaması ve bu analiz sürecinin analizinin başlaması ve bunun da analizinin yapılması ile projenin iptal olmasına kadar giden döngüyü tanımlar.

Detaylı anlatıma gelirsek. Kapıdan içeriye elinde proje talep formu ile müdürünüz içeri girdi ve buyurdu ki bu proje yapıla. Hemen ekibinizin analiz tarafı projeyi analiz etmeye başladı ROI’ler belirlendi, toplantılar ayarlandı ama fark ettiler ki, bu projenin bir de cache sistemi olması lazım, hemen bir cache sistemi analizi planlandı, olası programlar belirlendi fakat proje atıyorum bir finans projesi olduğundan back-up sistemlerinin olması ihtiyacı doğdu, daha cache bitmeden back-up sistemi planlanması yapılmaya başlandı ve onun da analiz dosyası çıktı. Bir gün siz gayet her sabah olduğu gibi analiz yaparken fark ettiniz ki müdürünüze projenin iptal edildiği haberi gelmiş. Fakat siz elinizde 200 sayfalık bir analiz kitabı – ki daha yarısı yazılmış – ile müdürünüze bakıyorsunuz. İşte bu durum analysis paralysis’dir. Yani bir analizin gereğinden fazla detaylandırılıp başka analizler ile birleşerek daha da fazla analize ihtiyaç duyması durumuna denir.

Olası sebeplerini ele alırsak; 3

  • Modulleştirme ve birleştirmenin verdiği dayanılmaz cazibe,
  • Dizayna başlamadan önce tüm analizin tamamlanması gerekliliği,
  • Var olan sistemlerin yeniden yazılması ve planlanması için uygun şansın ortaya çıkması,
  • Bir seferde öğrenilmesi gerekilen çok şeyin olması – yeni yetme analist – yeni şeyler öğrendikçe, sürekli bir önceki işi tekrar ele alma.
  • Ara hedeflerin olmaması,
  • Sürekli artan ara hedeflerin olması – genellikle politikal kararlar,
  • Big Project Syndrome yaşanması; bu seferki istediğimiz her şeyi yapacak, en son toolları kullanıp, en son paradigmaları kullanacak, tüm yeni developerlar bunu yazacak, temiz ve düzenli bir sistem başlatacağız, ilk versiyonda daha önceki programlardan bir ya da iki tanesini içine alacak, vb…
  • Riskten kaçınma, hata yapmaktan korkma.

Bu konuda emin olun her yazılımcı ve analist maalesef bir kere bu hataya düşmekte. Bir sistem inşa ederken her zaman; ya şunu da içine alsa, bak burada double yapıyordum teke düşürürüm bunu yaptıktan sonra, ya şurada yeni bir pattern var onu da koyarsam içine, open source bir tool varmış onu da alayım analize gibi cümleler maalesef biz yazılımcıların içinde var, kanımız kaynıyor böyle şeyleri görünce. Fakat maalesef sonumuz projenin iptali olacak bir sürece giriyor. Sadece projenin iptali olsa ne güzel; analiz ve analiste olan güvenin azalması, kullanılacak yeni teknolojilere olan inancın azalması, yazılım biriminin itibarının zarar görmesi de bunların yanında kolay tamir edilemeyecek şeyler.

Burada kalın harflerle belirtmekte faide var, Analiz kötü değildir, aksine çok güzeldir, süper bir şeydir!

Bu Anti-Pattern’den Kurtulma Yöntemleri

Sonuçta ilk sizin başınıza gelmiyor, dünyada binlerce yazılım firması ve yüzbinlerce yazılımcı varken sadece dünyanın sonunu sizin göreceğini sanıyorsanız gerçekten kafanız çok güzel bir durumda demek. Neyse başta ne dedik, bu bir AP ve her AP’nin olduğu gibi bunun da kaçınma yolları bulunmakta.

Çözümleri ele alırsak;3

  • Modellerinizi küçük tutun. Onları birleştirmeyin. Büyük bir model oluşturmak size bilgi katmaz, aksine bilgiyi yokeder!
  • Baştan sona gitmenize gerek yok, fakat test yapılabilecek kadar analiz yapmanıza gerek var. Bu nasıl olacak? Gereksinimleri belirleyerek.
  • Bir “analist” işe almayın. Yazılımcı işe alın. Eğer bir yazılımcı bir gereksinimi nasıl analiz edeceğini bilmiyorsa, yakında öğrenecektir. Eğer bir analist nasıl sistemin inşa edeceğini bilmiyorsa onun “analizi” işe yaramazdır.
  • Eğer yönetimdeyseniz, teknik dokümantasyonu gözden geçirmeyi reddedin. Çalışan işlevselliği gözden geçirin. Eğer her döngüde yeni bir özellik görmüyorsanız, görene kadar milletin başına çökün.
  • Profesyonel yazılım mimarı işe alın – kiralayın. Sadece bir tane sizin işinizi görecektir, bir taneden fazla olmamalı! Mimarın takım lideri olmasına gerek yok – aslında eğer değilse daha güzel. Mimar yazılımın gereksinimlerinin analizini çıkartmakla da sorumlu olmamalı. O sadece kullanılan araçları ayarlamalı, takımı koordine etmeli ve diğer yazılımcıları desteklemeli. Temelin çılartılmasında mimardan başka kimse söz konusu olmamalı – bu sizi de içeriyor. Ve toplantılarda kimse ne toplu olarak ne de öneri olarak yapı hakkında bir şeyi önermemeli – bu Analysis Paralysis için zemin hazırlar.
  • Projenizi başlangıçta bir hedefle ve prototipi hazırlanmış biçinde ortaya çıkartın. Bir aydan fazla kod yazılmasın ve evet kötü algılanabilir ama elinizde kod olduğunda ve çalıştığında kimse size karşı gelemez. Sonrasında değiştirmeye ve güncellemeye başlayabilirsiniz. Prototipi olmayan bir proje ipsiz bir muma benzer ve bu durumda gerçekten Analysis Paralysis ortaya çıkar.

Bu konuda ilgili detaylı tartışmayı ve çeşitli deneyimleri okumak isterseniz, yazının çoğu kısmının araklandığı http://c2.com/cgi/wiki?AnalysisParalysis adresine girip bakabilirsiniz.

Kişisel Durumlarda Analysis Paralysis

Geçenlerde Scott Hanselman‘ın “Knowing too much code” adında bir makalesini okurken kendisi de Analysis Paralysis’e değindi. Fakat bu konuya değinmesi biraz daha farklıydı. Bir kişinin, gelişen bilgisi neticesinde, yeni projelerde, yeni teknolojileri ve bunların arasında oluşacak yeni sistemleri oturtmaya çalışması üzerine, içine girdiği karmaşayı tanımlarken kullandı. Ve aslında evet, maalesef öyle oluyor. gün geçtikçe şu gelmiş, bu varmış dediğimizde entegre etmeye çalışarak, aslında eskiden 3 günde olan işi 7 günde yapmaya başlıyoruz. İçimiz rahat oluyor ama proje gecikmiş oluyor. Geleceği düşünüp atomik işlemleri hesap etmeye çalışsak da gerçekten çok da gerek var mı? YAGNI You aren’t gonna need it! tam da burada işimize yarıyor. Tabii ki YAGNI hakkında daha detaylı bir makale de gelecek, hepsini yazacağım…

Sonuç

Her koşulda bu konuda tam bir fikriniz olduğunu düşünmekteyim. Artık Analysis Paralysis nedir biliyoruz, ortamlarda birisi dediğinde “hmm, evet haklısın, hmmm” diyebilecek bilgi düzeyine eriştiğimize göre. Bir Anti Pattern’i daha burada kapatmış oluyoruz.


  1. Anti-Pattern’in bu yazıda kısaltılmış hali. 
  2. Project Manager – prone yöneticisi 
  3. Peter Merel’in konuyla ilgili yazısından alınmış ve çevrilmiştir.