Olaylar

Projelerde geçmişte verdiğimiz yanlış kararlar asla peşimizi bırakmıyor. Özellikle yazılım alanında verilen kararların uzun yıllar boyunca aynı şekilde geçerli kalması pek yaşadığım bir durum değildi zaten. Hala da değil. Bu günlerde tek değişiklik bu yanlışlamanın çok daha sık olması. Müşteriler artık daha yenilikçi adımlar atmaya meyilli. Teknoloji hızla gelişiyor. Rakipler de artıyor.

Bu ortamda uzun zaman önce şöyle harika bir tasarım yapayım da her müşterinin istediği olsun beklentisini terk etmiştim. Bu yönde tek sıkıntım o değişiklikleri hızla uygulayabilecek teknikleri henüz kullanmıyordum. Son zamanlarda biraz bu tekniklere yatırım yaptım. Bu sayede aynı anda birçok değişikliği programın mevcut müşterilerini rahatsız etmeden yapabiliyorum.

Önümüzdeki fuar nedeniyle yeni bir projeye de başladık. Bu proje sayesinde değişik bir alan için makineler üretebileceğiz. Uğraştığımız temel konu makinenin kendi kendine doğru parametreleri öğrenmesi üzerine. Teknik olarak nispeten kolay bir sorun. Sadece matematik. Zor olan kısmı ise bu matematiği çok değişik müşteri yelpazesini memnun edecek şekilde paketlemek. Çoğu müşteriler hiçbir şey yapmadan makinenin öğrenmesini isteyecektir. Bunların da çoğu belki tek bir tuşa basmaya razı olacaktır. Çok daha teknik müşteriler ise daha teknik verileri görüp kararlarını ona göre vermek isteyecektir. Bu kullanım senaryolarını belirlemek için toplantılar yaptık. Bu senaryolar aynı zamanda işlemin hangi modülde, nasıl yapılması gerektiğini ve de hangi arabirimlere ihtiyacımız olacağını da belirleyecek.

Sonunda uzun tartışmalar sonunda veri toplamanın ve işlemleri yürütmenin benim programladığım kısımda yapılmasına karar verildi. Ben de ihtiyacım olan arabirimlerin sunulması karşılığında bir sorun görmediğimi söyledim. Bunun yanında ileride ihityaçlara göre bu algoritmanın başka modüllere kayabileceği uyarısını da yaptım. Büyük ihtimalle bu uyarım çoktan unutulmuştur ama ben görevimi yaptım.

Dün görüntü işlemeden M ile kullanabileceğim arabirimler üzerine konuştuk. İlk toplantılarda bana söz verilen arabirimlerin hiçbirini alamayacağımı öğrendim. Peki dedim, “fuara bir ay bile kalmadı ama. İşimi zorlaştırırsanız bütün makine yetişmez.” diye de ekledim. Herkesin projeye bakış açısı farklı tabii ki. Kullanıcı arabirimini yazan arkadaş tabii ki kullanıcı için doğru şeyi yapalım, bu iş bir kerede bitsin istiyor. Ben de öyle yapalım ama fuara yetişecek şeyleri buna göre belirleyelim dedim. Az ama doğru şeyleri yapmak herkes için daha iyi olabilir. M elimizdeki arabirimleri kullanmanın en iyi yol olduğunu savundu. Grup şefi fuar için son müşterinin işine yaramayacak ama bizim sistemi kolayca test edebileceğimiz bir arabirim daha iyi olur dedi.

Her zamanki gibi karma bir yol seçildi. Anlatmak istediğim olaylar bunlar değildi ama. Program içindeki olaylardan behsedecektim. Yıllar önce projede bir parametre dışarıdan bir etki olmadan değişirse bu değişikliği benim programıma bildirebilsin diye bir mesaj tanımladık. O zamanlarda bunun ileride ne büyük belalara yol açabileceğini düşünemedik.

Sorun bu mesajı aldığımda sadece parametrenin değiştiğini bildirmesiydi. Bu parametrenin hangi ürüne ait olduğu ve neden değiştiği hakkında hiçbir bilgi yoktu. Dolayısıyla bazı senaryolarda yapacak pek bir şeyim olmuyordu:

Senaryo: Bir ürün üretilmekte. O sırada arabirimde bir işlem yapılıyor ve bu işlem görüntü işleme biriminde bir parametrenin değişmesini tetikliyor. Bu değişimin mesajı gelmeden önce arabirimde başka bir ürün seçiliyor ve bu ürün üretilmeye başlanıyor. Sonra parametrenin yeni değeri merkeze ulaşıyor. Bu değişim mesajında ürün bilgisi olmadığından sistem bu yeni değeri o an aktif olan ürüne yazıyor. Bu hatayı gidermek için şimdilik ürün değişimlerinde ekstra bir bekleme süresi koyuluyor. Bu süre boyunca yeni ürün aktifleştirilmiyor. O zamana kadar eski ürünü ilgilendirebilecek değişimlerin merkeze bildirileceği umuluyor.  
Senaryo: Ürün parametrelinin görüntü işleme birimi tarafından öğrenilmesi. Bu işlemde makineden geçen ürünlerin hatasız olduğu varsayılıyor. Görüntü işleme öğrenme modu boyunca bazı ölçümleri topluyor ve öğrenme bittiği zaman bu ölçümler ile parametreleri hesaplıyor. Bu hesaplamalar bitince parametrelerdeki değişiklikler tek tek merkeze bildiriliyor. Yukarıdaki senrayoda olduğu gibi ürün bilgisi olmadığından arada yapılacak bir ürün değişimi bu parametrelerin bir kısmının önceki, kalanının da sonraki ürüne kaydedilmesine yol açıyor. Bu durumda iki ürünü de bozmuş oluyoruz. Ürün değişiminde kullandığımız ekstra bekleme süresi de burada bir işe yaramıyor çünkü sayısı belli olmayan çok fazla parametre mesajı gönderiliyor ve bunların işlenmesi kullanıcının beklemek istemeyeceği kadar uzun sürüyor.

Bunlar şimdiye kadar yaşadığımız, herkesin bildiği sorunlardı. Burada arkadaşla konuşmaya başladık. M bu mesajın doğru olduğunu, çünkü geçmişte olan bir olayı temsil ettiğini söyledi. Bu olayın olduğundan ve bu mesajın sadece bunu söylediğinden hiçbir şüphem yoktu. Sadece bu mesaj işime yaramıyordu. Şu örneği vermeye çalıştım:

Senaryo: Arabirimden iki işlem başlatalım. Bu işlemler kullanıcı açısından birbirlerinden bağımsız olabilir. Diyelim ki bu işlemler görüntü işleme biriminde aynı parametreyi değiştiriyor. Bu olay tabii ki kullanıcının varsayımını geçersiz kılıyor ama kullanıcının bunu bilmesine imkan yok. Arabirim programcısı bile bunu bilemiyor. Bu durumda merkezi birim aynı parametre için iki değişik mesaj alacak. Eğer bu mesajlar sadece gösterilecek olsa sorun yok diyebilirim ama bu mesajlarla iki değişik prosesle ilgili iki değişik güncelleme yapacaksam hangisinin kime ait olduğunu nasıl çözebilirim?

Burada zamanında vermiş olduğumuz yanlış ya da eksik bir kara yüzünden kullanıcının yaptığı proses ile bu prosesin en temel parçalara ayrılıp bunlar üzerinden haberleşilmesi bir uyumsuzluk yaratmıştı. Prosesler ve olaylar arasında bir bağ kalmamıştı. Bu prosesleri aynı anda işlememek gibi bir kural da tanımlanabilirdi ama bu durumun da kısmen otomatik tespit edilmesi lazım, yani ortak parametreler var mı ve proseslerin hangi özellikleri var sorularını her an çözebilmemiz lazım. Yoksa kullanıcı bazı durumlarda gereksizce beklemek zorunda kalacak. Ayrıca bu durum sadece arabirim üzerinden başlatılan işlemler için değil, görüntü işleme birimi içinde olan işlemler için de dikkate alınmalı.

Bence bir parametre içten bir nedenle bile değişse, nedensellik her zaman olacaktır. Mesaja en azından bu nedensellikle ilgili bilgiler eklememiz sorunu çözebilir. Ya da diğer uç noktaya giderek parametrelerin değişimini tetikleyebilecek işlemleri aynı anda çalıştırmayı engelleyebiliriz. Her işlem kendinden önceki işlemin tamamen bitmesini bekleyebilir. Bu yöntemi programımda kullandım ama bir süre sonra kullanıcılar bu işlemler birbirinden bağımsız ama neden aynı anda işletilmiyorlar diye şikayet de ediyor.

İş hayatında her gün bu basit program olayları yüzünden çok ciddi gerçek hayat olayları yaratabiliyoruz. Düzeltmeleri, iyileştirmeleri geciktirdikçe de sorunlar sadece büyüyor.

Bir yanıt yazın