Joel Testi: Daha iyi kod için 12 adım
From The Joel on Software Translation Project
arkadaşım sitende büyük bir açık var sitedeki açığı haclenmeden kapatırsan memnun olurum.
Joel Spolsky
9 Ağustos 2000, Çarşamba
SEMA’yı hiç duydunuz mu? SEMA, bir proje takımının ne kadar iyi olduğunu ölçmek için üretilmiş oldukça az bilinen bir sistem. Hayır, linki açmayın! Neler olup bittiğini anlamak yaklaşık altı yılınızı alır. Ben de, üst düzeyde sorumsuzca ve özensiz olarak kendi testimi hazırladım. Testin güzel yanı 3 dakika sürmesi. Kalan zamanda ise tıp okuyabilirsiniz.
Joel Testi
1. Kaynak kontrolü kullanıyor musunuz?
2. Bir adımda yeni bir sürüm (build) çıkarabiliyor musunuz?
3. Günlük sürümler çıkarıyor musunuz?
4. Hata veritabanı kullanıyor musunuz?
5. Yeni kodlar yazmadan önce hataları düzeltiyor musunuz?
6. Güncel bir takviminiz var mı?
7. Tarifnameniz (specification) var mı?
8. Programcılarınızın sessiz birer çalışma ortamı var mı?
9. Paranın satın alabileceği en iyi araçları kullanıyor musunuz?
10. Testçileriniz var mı?
11. İşe alımda adaylarınıza kod yazdırıyor musunuz?
12. Koridor testi kullanıyor musunuz?
Testin bir başka güzel yanı da her soruya yalnızca evet veya hayır diyerek cevap verebilmeniz. Günde yazılan kod sayısı veya dönüm noktası başına düşen hata sayısı gibi ölçütlerle uğraşmak zorunda değilsiniz. Her “evet” için takımınıza 1 puan verin. Ancak bu testi nükleer araştırma laboratuarı yazılımınızın güvenliğini test etmek için kullanmayın.
12 puan mükemmel, 11 puan kabul edilebilir ancak 10 veya daha düşük puandaysanız ciddi problemleriniz var demektir. Gerçekte ise çoğu yazılım organizasyonu 2 veya 3 puanla çalışır ve ciddi şekilde yardıma ihtiyaçları vardır çünkü Microsoft gibi firmalar tüm zamanlarda 12 puanla çalışıyor.
Tabii ki bu maddeler başarının tek etkeni değiller; özellikle mükemmel takımınız kimsenin istemediği bir yazılım üzerine çalışıyorsa. Ve bunların hiç birini uygulamadan dünyayı değiştirecek bir sonraki yazılımı üreten bir ‘silahşörler’ ekibi de düşünülebilir. Ancak normal şartlarda, bu maddeleri uyguluyorsanız işlerini zamanında teslim eden tutarlı bir ekibiniz var demektir.
1. Kaynak Kontrolü Kullanıyor musunuz?
Ticari kaynak yazılımları da kullandım, ücretsiz olan CVS’i de. Ve CVS’in iyi olduğunu söyleyebilirim. Ama kaynak kontrolü kullanmıyorsanız, programcılarınızı beraberce çalıştırmanın zorluğunu yaşarsınız. Programcıların, diğerlerinin ne yaptığını bilmesi mümkün değildir. Hatalar kolayca telafi edilemez. Kaynak kontrolünün bir diğer iyi yanı da kaynak kodu her programcının sabit diskinde kontrol edilmesidir. Kaynak kontrolü kullanarak büyük miktarda kod kaybeden hiçbir proje duymadım.
2. Bir adımda yeni bir sürüm çıkarabiliyor musunuz?
Şunu kastediyorum: Kaynak kodun son durumundan, piyasaya sürülecek bir sürüme ulaşmak kaç adımda gerçekleşiyor? İyi ekiplerde, başlangıç noktasından itibaren tüm kontrolü yapacak, her satırı tekrar derleyecek, tüm versiyonlarda, dillerde ve #ifdef kombinasyonlarında EXE’leri yaratacak, kurulum paketini yaratacak ve yayınlanacak ortamı oluşturacak (CD ROM, Internet sitesi vb.) tek bir script bulunur.
Eğer süreç bir adımdan fazlaysa, hata yapmaya meyillidir. Ve piyasaya sürme aşamasına yaklaştıkça çok hızlı bir son hatayı düzeltme, son EXE’leri oluşturma döngünüz olmasını istersiniz. Eğer kodu derlemek, kurulum hazırlayıcıyı çalıştırmak vb. gibi işlemler 20 adım sürüyorsa çıldırabilir ve aptalca hatalar yapabilirsiniz.
Bu nedenle, çalıştığım son şirket WISE’dan InstallShield’a geçti; Kurulum sürecinin bir script’ten otomatik olarak ve NT Scheduler’ı kullanarak gece boyunca çalışmasına ihtiyacımız vardı ve WISE gece scheduler ile çalışamıyordu, biz de vazgeçtik (WISE’ın kibar çalışanları son sürümlerinde gece derlemeyi destekleyeceklerini söylediler).
3. Günlük sürümler çıkarıyor musunuz?
Kaynak kontrolü kullanırken bazen bir programcı kazayla derlemeyi bölecek bir kod teslim eder. Örneğin yeni ekledikleri bir kaynak dosyasını yollamayı unuturlar ve kendi makinelerinde sorunsuz derlenen bir kod, kod havuzunda sorun çıkarır. Böylece mutlu ve rahat bir şekilde evlerine dönerler ancak başka kimse çalışamaz ve geri kalan herkes eve mutsuz bir şekilde dönmek zorunda kalır.
Derlemeyi durdurmak oldukça kötüdür (ve sık yapılır) ve günlük derlemeler, hiçbir hatanın fark edilmeden geçilmemesine yardımcı olurlar. Büyük ekiplerde hataların hemen çözülmesini sağlamanın iyi bir yolu gün ortasında örneğin öğlen derleme yapmaktır. Herkes öğle yemeğinden önce mümkün olduğu kadar kontrol yapar. Geri geldiklerinde derleme tamamlanır. Çalıştıysa mükemmeldir! Herkes kaynak kodunun son halini kontrol eder ve çalışmaya devam eder. Eğer derleme başarısızsa siz hatayı düzeltirsiniz ve herkes bir önceki sürümle çalışmaya devam eder.
Excel takımında derlemeyi durduran hatayı yapanlara uyguladığımız bir ceza vardı. Bir sonraki hataya kadar derlemenin bakıcılığını yapmak zorundaydı. Bu derlemeyi duraklatmamak ve derleme sürecindeki işlerin yükümlülüğünü sıraya sokmak için iyi bir yöntemdi ve bir süre sonra herkes nasıl çalışılacağını öğrendi.
Günlük derlemeler hakkında daha fazlası için Günlük Sürümler Arkadaşınızdır makalemi okuyun.
4. Hata Veritabanı Kullanıyor musunuz?
Ne söylediğinizle ilgilenmiyorum. Eğer kod yazıyorsanız, bir kişilik ekipte bile olsa, koddaki hataları listeleyen organize edilmiş bir veritabanınız yoksa kalitesiz kod üretirsiniz. Çoğu programcı hata listelerini akıllarında tutabileceklerini düşünür. Saçma. Aynı anda iki veya üç hatadan fazlasını hatırlayamam ve ertesi sabah veya piyasa sürme telaşında bunlar unutulur. Hataları kesinlikle resmi olarak takip etmelisiniz.
Hata veritabanları karmaşık veya basit olabilir. Kullanılabilir en küçük hata veritabanı her hata için şu bilgileri tutmalıdır: • Hatayı yeniden üretmek için gerekli adımların tamamı • Beklenen davranış • Hatalı davranış • Hatanın kime atandığı • Çözülüp çözülmediği
Eğer sizi engelleyen hata takip yazılımının karmaşıklığıysa, yalnızca bu alanları içeren 5 sütunlu bir tablo yapın ve kullanmaya başlayın.
Daha fazlası için Sancısız Hata Takibi makalemi okuyun.
5. Yeni Kod Yazmadan Önce Hataları Düzeltiyor musunuz?
Microsoft Word for Windows’un ilk sürümü bir “ölüm marşı” projesiydi. Sonsuza kadar sürdü. Sürekli ayağı kaydı. Ekip saatlerce saçma uğraşlar verdi, proje tekrar tekrar ertelendi ve stres inanılmaz düzeydeydi. Yıllar sonra piyasaya sürüldüğünde, Microsoft tüm ekibi Cancun’a tatile gönderdi ve ciddi bir sorgulamaya başladılar.
Fark ettikleri, proje menajerlerinin sürekli olarak programcıları takvime uymaya zorlamaları ve hata takibinin takvimin bir parçası olmaması sebebiyle çok kötü kod yazılmasıydı. Hataları azaltmaya yönelik bir çaba yoktu. Hikaye bir programcının, bir satır yazının yüksekliğini ölçen kod yerine yalnızca “return 12;” yazması ve hatanın kendisine ne kadar zamanda döneceğini beklemesine kadar uzanır. Takvim hataya dönüşmek üzere bekleyen özellikler listesinden ibaretti. Modern literatürde buna “sonsuz hata metodolojisi” deniyor.
Problemi çözmek için Microsoft “sıfır hata metodolojisi” dediği bir yöntemi benimsedi. Çoğu programcı koddaki hataların yönetim kararıyla azaltılamayacağını düşünerek bunu gülünç buldu. “Sıfır hata” herhangi bir anda en büyük önceliğin hataların çözülmesine verilmesini ifade eder. Çünkü;
Genellikle bir hatanın çözülmesi için ne kadar beklenirse çözümün (zaman ve para olarak) maliyeti o kadar fazla olur.
Örneğin derleyicinin yakaladığı bir yazım hatasını çözmek hafife alınacak basit bir iştir.
Programı ilk çalıştırdığınızda fark ettiğiniz bir hatayı kolayca çözersiniz çünkü kod hala aklınızdadır.
Birkaç gün önce yazdığınız kodda ortaya çıkmış bir hatayı bulmak için kodu incelemekle biraz vakit geçirirsiniz ancak kodu kolayca hatırlarsınız ve hatayı kabul edilebilir bir zamanda çözersiniz.
Ancak birkaç önce yazdığınız bir kodun çoğunu muhtemelen unutmuşsunuzdur ve bunu düzeltmek çok daha zordur. Bu arada başka birinin yazdığı kodu düzeltiyor olabilirsiniz ve o Aruba’da tatilde olabilir, bu durumda koddaki hatayı çözmek bilimsel araştırma yapmaya benzer: yavaş, metodolojik ve çok titiz olmalısınız, buna rağmen çözümü keşfetmenin ne kadar zaman alacağını bilemezsiniz.
Ve zaten piyasaya sürmüş olduğunuz yazılımda bir hata bulursanız, telafi maliyeti oldukça yüksek bir durumla karşı karşıya kalırsınız.
Hataları hemen çözmenin en önemli sebebi daha az zaman almasıdır. Başka bir sebep de kodu yeniden yazmak ve hatayı düzeltmek arasında zaman karşılaştırması yapmanın daha mümkün olmasıdır. Örneğin size bir listeyi sıralayan bir kodu ne kadar zamanda yazacağınızı sorsam, oldukça iyi bir tahminde bulunabilirsiniz ancak Internet Explorer 5.5 kurulu bir ortamda kodunuzun hatasını ne kadar zamanda çözeceğinizi nasıl belirleyeceğinizi sorsam tahmin bile edemezsiniz çünkü muhtemelen hatanın sebebini bilemezsiniz. Bulmak 3 gün de sürebilir, 2 dakika da.
Eğer çözülmeyi bekleyen hatalarla dolu bir takviminiz varsa, bu takvime güvenilemez. Fakat tüm hataları çözdüyseniz ve takviminizde sadece yeni kodlar varsa, çok daha isabetli bir takviminiz vardır.
Hata sayısını sıfırda tutmakla ilgili başka bir harika şey de rekabete çok daha çabuk cevap verebilmenizdir. Bazı programcılar bunu piyasaya çıkmaya her an hazır olmak olarak düşünür. Rakibiniz yazılımına müthiş bir özellik ekler ve müşterilerinizi çalmaya başlarsa, yalnızca o özelliği kendi yazılımınıza ekleyip birikmiş bir çok hatayla uğraşmadan yazılımınızı piyasaya sürebilirsiniz.
6. Güncel bir takviminiz var mı?
Ve tkvimler. Eğer kodunuz iş için önemliyse, ne zaman biteceğini bilmenin de iş için bir çok nedeni vardır. Progracılar takvimler konusunda huysuzdur. "Bittiği zaman biter!" diye yakarırlar.
Ne yazık ki işin aslı böyle değil. Kodu piyasaya sürmek için işin ihtiyacı olan bir çok planlama kararı vardır: Demolar, ticari gösteriler, reklamlar vb. Bunu yapmanın tek yolu da bir takvimi takip etmek ve bunu güncel tutmaktır.
Bir takvime sahip olmanın bir diğer önemli yanı da sizi hangi özelliklerin ekleneceğini belirlemeye zorlamasıdır. Daha sonra da en önemsizleri belirlemeye ve mükemmeliyetçilik hatasına düşmeden bunlardan vazgeçmeye zorlar.
Takvim hazırlamak zor olmak zorunda değil. Mükemmel takvimler hazırlamanın kolay yollarını öğrenmek için Painless Software Schedules (Sancısız yazılım takvimleri) makalemi okuyun.
7. Tarifnameniz (specification) var mı?
(Tarifname çok hoş durmadığı için spec olarak kullanmaya devam edeceğim)
Spec yazmak diş fırçalamaya benzer. Herkes iyi bir şey olduğunu söyler ama kimse yapmaz.
Sebebini bilmiyorum ama muhtemelen programcıların döküman yazmaktan nefret etmesinden kaynaklanıyor. Sonuç olarak, yalnızca programcılardan oluşan takımlar bir problemi çözmeye kalktıklarında, çözümlerini döküman yerine kodda belirtmeyi tercih ediyorlar. Önce bir spec üretmektense doğrudan probleme dalıp kodu yazmak istiyorlar.
Tasarım aşamasında problemle karşılaşırsanız, bunu yalnızca bir kaç satır değiştirerekkolayca çözersiniz. Kod yazıldıktan sonra problem çözmenin maliyeti hem zaman açısından hem de duygusal açıdan (insanlar yazdıkları kodu silip atmaktan nefret ederler) oldukça yükselir, bu da problem çözmeye karşı direnç oluşturur. Bir spec'ten oluşturulmayan yazılım genellikle kötü tasarlanır ve takvim kontrolden çıkar. Netscape'in başına gelen buydu. İlk dört sürümde yazılım içinden çıkılmaz bir hal aldı ve yönetim kodu baştan yazmak gibi aptalca bir karar verdi. Daha sonra aynı hata Mozilla ile yapıldı ve alfa sürümüne ulaşılması yıllar aldı.
Benim teorime göre bu problem programcıları daha gönülsüz yazarlar yapmak için onlara yazma kursu aldırmakla çözülebilir. Başka bir çözüm ise işe yazılı spec üreten zeki program menajerleri almaktır. Her iki durumda da "spec yoksa kod da yok" kuralını idrak etmelisiniz.
Spec yazmak hakkında her şeyi 4 bölümlük yazımdan öğrenin.
8. Programcılarınızın sessiz birer çalışma ortamı var mı?
Bilişim çalışanlarına çalışma alanı, sessizlik ve gizlilik sağlamanın üretkenliğe pek çok -yazılı- faydası vardır. Peopleware bu faydaları dökümante eder.
Sorun şu: Hepimiz programcıların tamamen işe konsantre olarak ve çevreden soyutlanarak "havaya girdiklerinde" en iyi şekilde çalıştıklarını biliriz. Zaman duygusunu kaybederler ve tam konsantrasyonla harika bir iş ortaya koyarlar. Bu onların en verimli işlerini yaptıkalrı zamandır. Yazarlar, programcılar, bilimadamları ve hatta basketbolcular size havaya girmekten bahsedebilirler.
Sorun "havaya girmenin" o kadar kolay olmaması. Ölçmek gerekirse, tam verimle çalışmaya başlamak 15 dakika kadar alır. Bazen yorgunsanız veya o gün zaten yeterince yaratıcı işler yaptıysanız havaya giremezsiniz ve günün geri kalanını boş işler yaparak, Internet'te gezerek ve Tetris oynayarak geçirirsiniz.
Bir diğer sorun da bu durumdan çıkmanın çok kolay olmasıdır. Gürültü, telefon çağrıları, öğle yemeği, kahve için Starbucks'a kadar 5 dakika araba kullanmak zorunda olmak ve çalışanlar tarafından rahatsız edilmek -özellikle çalışanlar tarafından rahatsız edilmek- konsantrenizi bozar. Bir çalışanın bir soru sorması ve bir dakikalık kesintiye yol açması, tekrar havaya girene kadar size yarım saat kaybettirir ve bu durumda üretkenliğiniz ciddi bir tehdit içindedir. Dotcom'ların tasarlamayı sevdiği, pazarlamacı elemanların programcıların hemen yanında telefonda bağırdığı, gürültülü bir ortamdaysanız, çalışmanız bölündükçe veriminiz düşecektir ve tekrar bu duruma giremeyeceksiniz.
Programcılarla bu durum daha da zordur. Verimlilik, kısa süreli bellekte yer alan ufak detayların tümüyle baş edebilmekle ilgilidir. Herhangi bir tür kesinti bu detayların bütünüyle çökmesine neden olabilir. İşe devam etmeye başladığınızda (kullanıyor olduğunuz yerel değişken adları, arama algoritmasını yazarken nerede kalmış olduğunuz gibi) bu detayları hatırlayamaz olursunuz ve bunlara bakarak zaman kaybedersiniz, bu da sizi eski hızınıza kavuşana kadar yavaşlatır.
İşte basit çözüm. Şöyle diyelim, (kanıtlar da bunu gösteriyor ki) eğer bir programcıyı, bir dakikalığına bile, bölersek, aslında 15 dakikalık bir verimliliğini uçurmuş oluruz. Örneğin, iki programcıyı, Jeff ve Mutt, birbirinin yanına, standart bir Dilbert'le kaplı ofiste yer alan, açık kübiklere koyalım. Mutt strcpy işlevinin Unicode ismini hatırlayamamış olsun. Bu durumda eğer bir kaynaktan bakarsa 30 saniye sürecektir, Jeff'e sorarsa 15 saniyesini alacaktır. Dolayısıyla hemen yanındaki Jeff'e sorar. Jeff bölünmüş olur ve 15 dakika verimlilikten kaybeder (Mutt'un 15 saniyesini kurtarmak için).
Şimdi de bunları duvarlar ve kapıyla ayrılmış ayrı ofislere taşıyalım. Artık Mutt bu işlevin adını hatırlayamadığında aramak zorunda olacaktır ve 30 saniye alacaktır, ya da yine Jeff'e sorabilir, fakat bu 45 saniye sürecek ve ayağa kalkmasını gerektirecektir (bir programcının içinde bulunduğu kondisyon durumu için kolay bir durum değil!). Dolayısıyla arayacaktır. Mutt 30 saniye kaybetmiştir, ama Jeff'in 15 dakikasını kurtarmış olduk. Aaah!
9. Paranın satın alabileceği en iyi araçları kullanıyor musunuz? Derlenen bir dilde kod yazmak sıradan bir ev bilgisayarında hızlıca yapılabilecek en son şeylerden biridir. Eğer derleme süreci bir kaç saniyeden daha fazla zaman alıyorsa, en iyi ve en son bilgisayarı almanın zamanı gelmiştir. Derleme işlemi 15 saniye bile sürüyor olsa, programcılar bu sırada sıkılacak ve The Onion'ı okumaya başlayacaktır, ki bu saatlerce verimliliği öldürecektir.
Tek monitörlü bir sistemde GUI kodunu hatadan arındırmak imkansız değilse bile acı vericidir. GUI kodu yazıyorsanız çift monitör işleri çok daha kolaylaştıracaktır.
Çoğu programcı araç çubukları veya simgeler için bitmap dosyalarını düzenlemek zorunda kalır ve çoğu programcının bunun için iyi bir yazılımı yoktur. Bir simgeyi düzenlemek için Microsoft Paint kullak bir şaka mıdır, fakat çoğu programcının yapmak zorunda kaldığı şey budur.
En son işimde, sistem yöneticisi hard diskte gereğinden fazla yer kullandığımı belirten otomatik hazırlanmış bir spam atıp durmaktaydı. Şunu belirtmeliyim ki, bugünün fiyatlarıyla hard disk alanını genişletmenin maliyeti, kullandığım tuvalet kağıdının maliyetinden bile daha az. Klasörümü düzenlemek için harcayacağım 10 dakika bile bir verimlilik kaybı olacaktır.
En iyi geliştirme takımları programcılarına işkence yapmazlar. Yeterince iyi olmayan araçlardan kaynaklanan en ufak kızgınlıklar bile programcıları mutsuz yapacaktır. Mutsuz bir programcı ise verimsiz bir programcıdır.
Bütün bunlara ek olarak... programcılara kolayca en son, en havalı şeyler verilerek rüşvet verilebilir. Rekabetçi maaşlar ödeyerek sizin için çalışmalarını sağlamak yerine çok daha ucuz bir yoldur!
10. Testçileriniz var mı? Eğer takımınızın kiralık testçileri yoksa, her 2-3 programcı için en az bir, ya hatalı programları piyasaya sürüyorsunuzdur ya da bir testçinin 30$/saate yapacağı işi bir programcıya $100/saate yaptırarak paranızı çar çur ediyorsunuzdur. Testçileri atlamak son derece yanlış bir ekonomidir, çoğu insanın bunu anlamamış olmasını hayretle izliyorum.
Bu konuda yazdığım Testçilerinizin Olmamasının Neden Olduğu En Büyük Beş Hata adlı yazımı okuyun.
11. İşe alımda adaylarınıza kod yazdırıyor musunuz? Gösterisini yapmasını istemeden bir sihirbazı işe alır mıydınız? Tabii ki hayır.
Yemeklerini test etmeden bir aşcıyı düğününüze yemek hazırlaması için kiralar mıydınız? Şüphe duyarım. (Marge Teyze olmadığı sürece ve onun "ünlü" kekini yapmanıza izin vermediğiniz durumda sizden nefret edeceği halde.)
Her gün, programcılar etkileyici bir özgeçmiş nedeniyle ya da görüşmeci onlarla sohbetten hoşlandığı için kiralanmakta veya işe alınmaktadır. Ya da ıvır zıvır sorular sormuş oldukları için ("CreateDialog() ile DialogBox() arasındaki fark nedir?" gibi), halbuki bu, belgelere bakılarak rahatça cevaplanabilir. Programlamayla ilgili yüzlerce ıvır zıvırı ezberlemiş olmalarına dikkat etmiyorsanız bile, kod üretebiliyor olmalarına önem verin. Daha da kötüsü, "AHA!" soruları sormuşlarsa: cevabı bildiğiniz zaman kolay gelen, ama bilmediğinizde imkansız olan sorular.
Lütfen, bunu yapmayı bırakın. Mülakat sırasında ne istiyorsanız yapın, ama adayın biraz kod yazmasını sağlayın. (Öneri için Mülakat İçin Gerilla Rehberi adlı yazıma bakın.)
12. Koridor testi kullanıyor musunuz? Koridor testi, koridordan geçen ilk kişiyi tutup henüz yazmış olduğunuz kodu kullanmasını sağlamak olarak tanımlanabilir. Bunu beş kişiye yaparsanız, kodunuzdaki kullanılabilirlik problemleri hakkında öğrenebileceklerinizin %95'ini öğrenirsiniz.
İyi bir kullanıcı arayüzü tasarımı düşündüğünüz kadar zor değildir ve müşterilerinizin ürününüzü sevmesi ve alması için son derece önemlidir. UI tasarımı üzerine ücretsiz çevrimiçi kitabımı okuyabilirsiniz, programcılar için iyi bir başlangıçtır.
Ama kullanıcı arayüzleriyle ilgili en önemli şey, birkaç kişiye programınızı gösterdiğiniz zaman (5 ya da 6 kişi yeterlidir) bu kişilerin kullanırken karşılaştığı en önemli sorunları farkedecek oluşunuzdur. Jakob Nielsen'in bunun nedenini açıkladığı yazıyı okuyun. UI tasarım yeteneğiniz yoksa bile, koridor testi yapmaya kendinizi zorladığınız takdirde, arayüzünüz çok daha iyi olacaktır.
Joel Testini Kullanmak için Dört Yol
1. Kendi şirketinizi oylayın ve bana bahsedin ki dedikodusunu yapabileyim. 2. Programlama takımızın yöneticisiyseniz, bu listeyi kontrol listesi olarak kullanın. 12 aldığınızda programcılarınızı yalnız bırakabilir ve müşterilerinizin onları rahatsız etmesini engellemeye zamanınızı harcayabilirsiniz. 3. Bir programlama işini almaya karar vermeye çalışıyorsanız, olası işvereninize bu testten kaç alacağını sorun. Eğer çok düşükse sorunları düzeltebilecek yetkinizin olacağına garanti isteyin. Aksi takdirde sinirleneceksiniz ve verimsiz olacaksınız. 4. Bir programlama takımının değerine karar verecek olan bir yatırımcıysanız, ya da başka bir şirketle birleşmekte olan bir şirketiniz varsa, bu test size hızlı bir yol gösterebilir.
