Kötü Programcıya Övgü

0
FZ
Harold kötü bir programcıydı, gerçekten kötü bir programcı. Hani hem kendisi hem de etrafindaki herkes için kendine yeni bir meslek bulması gereken türden. Ama Harold iyi biriydi ve bir işte ömür boyu çalışacaklardandı; çok uzun süredir şirketteydi. Ezelden beri alt kademelerde olan bir programcısıydı, hiçbir zaman terfi etmedi, her sene maaşına en düşük zammı aldı ve yeri çok değiştiriliyordu. Ama kimse onu işten çıkarmak istemiyordu. Böylelikle ne zaman yeni bir proje başlasa ve yeni adama ihtiyaç olsa, Harold'ın takımının müdürü bu durumu fırsat bilip onu yönetmek zorunda kalacak bir sonrakı bahtsız kişiye gönderiyordu Harold'ı. Bir seferinde bu kişi ben oldum.
Kötü Programcıya Övgü

Bu olay, bir şirkette uzun yıllar kalmanın günümüzdekinden daha anlamlı olduğu 1980'li yıllarda geçiyordu. Yönettiğim ekip çok istekliydi. Belirleyici özelliğimiz daha iyi bir takım olma isteğimizdi ve bu hedef için de epey çalışıyorduk. İyi tanımlamış ve denenmiş süreçlerimiz vardı, gereksinim ve tasarım modelleme yaklaşımları geliştirdik ve gerçekleştirdik; gereksinimleri, tasarımı, kodu, test planlarını, test olaylarını, her şeyi denetleyen kapsamlı bir gözden geçirme yöntemi uyguladık ve bu yöntemi aynı zamanda mükemmelleştirdik. Hatta yenilikçi bir test etme yöntemi geliştirdik. Ve daha etkin olduğumuz zaman, daha da etkin hale gelmek için çok çalışıyorduk. Sonra takıma Harold katıldı.

Harold ekibe katılmadan çok daha önce ekipçe bir anlaşma yapmıştık: hiç kimsenin kötü bir işini projeye dahil etmeyecektik, o iş ister baş tasarımcıdan gelsin, ister test koordinatöründen, isterse de müdürden. Ve hatta Harold'dan gelse bile. Ekibin her üyesinin %100 başarılı olması için gerekli tüm süreçleri, şablonları, desteği, kaynakları, eğitimi, gözden geçirmeyi ve geribildirimi sunuyorduk. Bu başarı oranını ölçen metrikleri bile tanımlamıştık. Harold bize katıldığında ona sistemimizi gösterdik ve eğer bizim ekibin bir üyesi olacak ise bahsettiğimiz süreçlere tam olarak uymanın şart olduğunu açık açık belirttik. Bu disiplin herkes için geçerliydi, Harold için bile.

Bir Program Yeniden Tasarlanıyor

Harold'a verilen ilk görev kolay bir program sayılırdı. Kodlamaya başlamadan önce aldığı pakette iyice gözden geçirilmiş gereksinimler, tüm grafikleriyle birlikte ortaya konmuş görsel tasarım, test koşullarını geliştirmesi için kullanılabilecek, geçerliliği kanıtlanmış bir süreç ve biten kodun gözden ne zaman geçirileceğine dair bir zaman planı vardı. Harold kodu yazarken proje ile ilgili başka meseleler gündeme geldi ve bu yüzden kodunu gözden geçirme tarihini aksattık. Harold gözden geçirmemiz için bize kodunu getirdiğinde birim testlerini çoktan yazıp geçmişti. Bu durum normal ve beklenen süreçteki çalışma sırasına uymuyordu ama Harold'ın hatası değildi ve yazdığı program çalışıyordu, en azından Harold'a göre. Ancak kodu incelemeye başladığımızda gördük ki yazdığı program gözden geçirilmiş ve onaylanmış tasarıma kesinlikle uymuyordu. Harold ekibin sistem tasarımcılarına alternatif bir tasarım sunup bunu savunmamıştı, kendi kafasına göre ne şekilde istiyorsa öyle kod yazmıştı. Bu yüzden de yazdığı kod incelemeyi başarı ile geçemedi. Harold şok geçirmişti: "... ama tüm birim testleri geçti!..." diye bağırmıştı. İtirazları ve şikayetleri kurulum yöneticisine kadar çıkmıştı: "... çalışan bir şeyi yeniden yazmamı istiyorlar!..." Neyse ki bu protestosu görmezden gelindi ve yönetici de ekibin tarafını tuttu. Harold programı tekrar yazmak zorunda kaldı, bu sefer özgün belgelerdeki tasarıma uyacak şekilde. Kod yeniden gözden geçirme sürecine girdiğinde ilk tasarıma uygundu, iyi çalışıyordu ve bir iki basit yorum dışında hiç sorun çıkarmadan süreci başarı ile geçmişti.

Bazen yazılım süreçleri tüm bireysellik ve yaratıcılık izlerini silip atacak şekilde uygulanıyormuş gibi görünür.

Daha İyi Bir Takım, Daha İyi Bir Sistem

Takımca ilginç bir şey fark ettik: Harold başarısız bir programcı olduğu için daha iyi bir takım haline gelmiştik: sürecimizi daha iyi tanımlamış ve daha sıkı uygulamaya başlamıştık, ölçümleri kurmuş ve daha tutarlı bir şekilde almaya başlamıştık, programcılara (özellikle Harold'a) destek ve yönlendirme sağlamayı daha iyi öğrenmiştik. Her şeyden önemlisi, bir takım hedefi ve etiği benimsemiştik: asla kötü iş kabul etmeyecektik ve iş yapamayan, daha zayıf bir takım üyesini de kolayca takımdan çıkarmayacaktık; kişinin takım standartlarına ulaşabilmesi için ne gerekiyorsa onu yapacaktık. Takım üyeleri bu hedefi desteklediği, kaynaklardan yararlandığı ve geçerli ürünler ürettikleri sürece takımımızın bir parçası olabilirdi ve takım onları profesyonel olarak gözetecekti. Bu etik bizi daha iyi bir ekip yaptı.

Modern fizik, bir sistemin davranışının o sistemin tek tek parçalarının davranışının doğrudan bir fonksiyonu olmayabileceğini öğreniyor. Bir saatin içindeki çark dişlerinin hepsi büyük çark dişi olmak zorunda değil. Bazen bir sistemde daha az iyi parçalar kullanarak daha iyi davranış elde edebilirsiniz. Bazen en iyi takımlar sadece süper kahramanlardan oluşmazlar ve eğer bir takım bir sınırlamayı aşmakta kararlı davranırsa, kendi personelinden kaynaklanan bir sınırlandırma bile olsa, o sınırlandırmanın olmadığı durumundakinden bile daha iyi bir takım haline gelebilir. Kötü programcıları işe almalıyız demiyoruz ama takımlar bir kutudaki birbirine bağlanmamış somunlar ve civatalar gibi değiller, onlar bir sistem. Etkin bir takımın dinamikleri bazen göründüğünden daha karmaşık ve inceliklidir ve performansı düşük kişilerin projeye ürettikleri ürünlerin ötesinde ve farklı etkileri olabilir.

Bazen yazılım süreçleri tüm bireysellik ve yaratıcılık izlerini silip atacak şekilde uygulanıyormuş gibi görünür. Sanki sistem kurmak, düşünce gerektirmeyen bir süreç haline getirilmeye çalışılır. Bu takımda biz bunu özellikle yapmamaya özen gösterdik; ama aynı zamanda kimsenin değerini ve getirisini düşünmeden herhangi birşeyi herhangi bir anda değiştirmesine izin vermemeye dikkat ettik. Kuşkusuz kimseye sadece tembellikten, yanlış anlamalardan veya yetersizliklerinden dolayı değişiklik yapmalarına izin vermedik. Ve kimsenin başarısız olmasına da izin vermedik.

Harold'ın Kurtuluşu

Harold'ın kodu onaylandığında kendisi herkesi şaşırtan şu sözleri sarf etti: "Biliyor musunuz, bu tasarım benim daha önce yaptığımdan çok daha iyi." Aslında o andan sonra Harold bizim yaklaşımımıza tamamen inanmaya başladı ve yine herkesi şaşırtacak şekilde bizim ekibin ve sürecin misyoneri gibi davranmaya başladı. Bununla kalmadı, ekibin sürecine ve kullandığı araçlara da katkıda bulundu, elbette uygun ekip incelemeleri ve onaylarından sonra.

Ekibimiz yazılan bir kodun inceleme esnasında varabileceği en üst kalite seviyesini "OLDUĞU GİBİ" olarak belirlemişti. Yani incelenen kodda hiçbir hata yoksa, hiçbir işlevsel sorun, tasarıma dair bir şüphe yoksa, belgelendirme tamamen yapılmışsa ve imla hatası dahi yoksa bu sistem "OLDUĞU GİBİ" kabul edilebilir, mükemmel bir sistem olarak etiketleniyordu. Projenin yaşam döngüsü boyunca gerçekleştirdiğimiz 500 incelemeden sadece tek bir kişinin hazırladığı bir kod "OLDUĞU GİBİ" kalite seviyesiyle geçebilmişti. O kişi Harold idi.

Phillip G. Armour'ın "In Praise of Bad Programmers" başlıklı makalesinden yazarın izni ile Elif T. Kuş, Yaşar Safkan ve Emre Sevinç tarafından Mart 2010'da çevrilip yayımlanmıştır.

Kaynak: http://ileriseviye.org/blog/?p=3025

Görüşler

0
Tarık
Çok soğuk bir hikaye.

Çok soğuk başarısız programcı VS Başarılı programcı karşılaştırması

Bana programcılık, hacker hikayesinden çok robotize ISO9001, OHSAS18001 kalite standardı başarım kılavuzlarını hatırlattı.

İnsanların neden medya hacker lığına özendiklerini şimdi az biraz anlayabiliyorum. Zira uzmanlık arttıkça herkesin ilgisini çeken edebiyat yerini böylesi soğuk hikayelere bırakıyor anlaşılan. Biraz insan edebiyatı yahu!, dönün artık şu Mars atmosferinden...!
0
ekomut
Kesinlikle katılıyorum.
0
mtkocak
İhsan berbat bir programcıydı. Çalıştığı işyerinde, beyaz duvarlarda oynaşan huzursuz jaluzi gölgelerinin verdiği mutsuzluğun otomatik termostatlı klima sesleriyle karıştığı zamanlarda çalışırdı hep. Klima rüzgarında titreşen jaluzi yaprakları her zaman koda eklemeyi unuttuğu son class yüzünden çöken moralinin getirdiği melankoliyle cıvıldaşmakta, fotokopi kağıtlari ise bu soğuk gecelerde etrafta uçuşmaktaydı.
0
Tarık
...
0
Tarık
...
0
SydBarrett
İşini severek, samimiyetle yapmaya çalışan, farklı düşünen ve özeleştiri yapabilen insanın mutlu sonu.

Motive eden bir yazı, Teşekkürler.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Pavuk???

m1a2

Hemen söyleyelim, bu `Pavuk` ne oluyor? Pavuk özellikle son haliyle `wget`e ciddi bir rakip oluyor... Malum, `wget` Linux`taki temel araçlardan birisidir. Bendeniz de lynx, wget vb. kod tabanı iyice oturmuş, mature programları değiştirme taraftarı değilimdir. Alışkanlıklar bu tip temel araçların değiştirilmesine de çoğunlukla engeldir. 1-2 yıl önce ismini duyduğum fakat `wget`e duyduğum saygıdan ötürü incelemeye kalkışmadığım :)`pavuk`u bir süredir deniyorum. Pek te memnun kaldım. Siz de bir deneyin isterseniz. Nereden mi? İşte şuradan.

Türkçe Wiki/Blog Melezi Wikepage'in Yeni Sürümü Çıktı

anonim

Veritabanı gerektirmeyen ve yaklaşık 30 KB büyüklüğünde wiki / blog melezi Wikepage'in yeni sürümü Opus 11 2006.3 çıktı. Çoğunlukla hataları giderilen ve optimize edilen bu sürümde, birkaç ufak özellik de eklenmiş. Ayrıntılı bilgiyi wikepage sitesinde bulabilirsiniz.

Not: Ön tanımlı olarak İngilizce seçili gelen Wikepage'i Türkçe kullanabilmek için aynı sayfadan Türkçe dil dosyasını da indirmeniz gerekiyor.

Matematik ve programlama gerçek hayatta ne işe yarar:emeksensin.com ve rengarenk

FZ

Emeksensin.com'da en son yaptığımız yeniliğin adı Rengarenk. Rengarenk özelliği ile eserleri renklerine göre arayabiliyorsunuz. Buradan deneyip görebilirisiniz: http://www.emeksensin.com/rengarenk. Renk arama özelliği dünyada az sitede görebildiğimiz bir özellik çünkü bunu yapabilmek için bazı zor problemleri çözmek gerekiyor. İlk problem eserin resmindeki binlerce renkten önemlilerini seçmek. Bunu yapan birçok görüntü işleme algoritması var. Biz OpenCV kütüphanesini kullanarak bir gerçekleme yaptık.

MuraveyWeb 0.2 CMS - Ruby on Rails ile içerik yönetimi...

anonim

CMS kelimesini görür görmez "Yine bir PHPNuke türevi mi?" diye düşünürek bu haberi okumayacak olanlarınız ciddi bir yanılgıya düşecekler.

Çünkü MuraveyWeb Ruby on Rails teknolojisi ile yazılan ve "Acı çektirmeden site yönetmeyi" vaadeden bir CMS. Üstelik bunu dizayn özgürlüğünüzü de kısıtlamadan yapıyor.

Dikkat Edilmesi Gereken 10 Semantik Uygulama

FZ

Web 3.0 ve semantik web laflarını artık FM'de de daha sık duyar hale geldik.

Read / Write Web'deki güncel bir yazı yakından takip edilmesi gereken 10 semantik web uygulamasından bahsediyor. Bunların arasında Hakia, PowerSet ve FreeBase gibi isimler de göze çarpıyor.

Belki de artık ontoloji gibi kavramları öğrenmenin, SPARQL, OWL gibi dilleri kurcalamanın ve AllegroGraph ve TopBraid Composer gibi araçlarla haşır neşir olmanın zamanı gelmiştir, ne dersiniz?