Joel a szoftverről szoftvermenedzsment egyszerűen
A Joel-teszt
Írta: Joel Spolsky (2000. augusztus 9.)
Fordította: Nagy Balázs
Lektorálta: Kovács Emese
Az eredeti cikk
Hallottál már a SEMA-ról? Az egy eléggé ezoterikus rendszerben méri le, hogy milyen jó is a csapatod. Jaj, várj, ne kövesd a linket! Legalább hat év, mire egyáltalán megérted a dolgot. Ezért létrehoztam a saját, meglehetősen megbízhatatlan, hanyag tesztemet, ezzel könnyedén felmérhetem szoftverfejlesztő csapatok minőségét. Az az előnye, hogy csak három perc az egész. A megspórolt idő alatt elvégezheted az orvosi egyetemet.
 | ||
 |
A Joel-teszt
|
 |
 |
||
Az a szép a Joel-tesztben, hogy minden kérdésre könnyen megkaphatod az egyszerű igent vagy nemet. Nem kell hozzá kinyomoznod a napi-új-sorok-száma és az átlagos-hibák-per-inflexiós-pont mutatókat. Csak adj egy pontot minden „igen” válaszra. Arra azonban vigyázz, hogy tényleg ne a Joel-tesztet használd annak felmérésére, hogy az atomerőművet vezérlő szoftvered biztonságos-e.
A 12 pontos eredmény tökéletes, a 11 elviselhető, de 10 vagy ez alatti pontszám esetén súlyos problémákkal állsz szemben. Az az igazság, hogy a legtöbb szoftvercég csupán kettő-három pontot érne el és tényleg szükségük lenne hathatós segítségre, mivel a Microsoft-típusú cégek folyamatosan 12-n pörögnek.
Persze, nem egyedül ezeken a tényezőkön áll vagy bukik a fejlesztés: hiába a remek szoftveres csapat, ha olyan terméken dolgozik, amelyre senkinek sincs szüksége. A jól szervezett munkától az embereknek nem lesz hirtelen nagyobb szükségük a termékre. Aztán elképzelhető egy olyan „mesterlövész” csapat, amely a fent említett lépések egyikét sem teszi meg, mégis képes olyan hihetetlen programot írni, ami megváltoztatja a világot. Ha ez a 12 pont megvan, akkor annyit legalább elmondhatsz, hogy van egy fegyelmezett csapatod, amely következetesen tartja a határidőket.
1. Használsz forráskövető rendszert?
Használtam kereskedelmi forgalomban kapható forráskövető rendszereket, és használtam CVS-t is, amely ingyenes, és hadd áruljam el: remek. Ám ha nem használsz forráskövető rendszert, arra fognak rámenni az idegeid, hogy megpróbáld rávenni a programozókat, hogy együtt dolgozzanak. A programozók nem tudhatják, mit csinálnak a többiek. A hibákat nem könnyű kibogozni és visszaállítani a működőképes állapotot. A forráskövető rendszerek másik szépsége, hogy maga a kód kint van a fejlesztő saját merevlemezén. Még nem hallottam olyan forráskövető rendszert használó projektről, ahol sok kód veszett volna el.
2. Megy a fordítás egy lépésben?
Ez alatt azt értem, hogy hány lépésben lehet előállítani a szállítandó terméket a legfrisebb forrásból? Jó csapatoknál egyetlen szkript letölti a teljes forráskódot, lefordít mindent, létrehozza a futtatható állományokat minden szükséges változatban és nyelven és #ifdef kombinációban, létrehozza a telepítőcsomagot, és legyártja a végső médiát – CDROM struktúrát, weboldalt, bármit.
Ha a művelethez több mint egy lépés kell, az hibalehetőségeket rejt magában. Ahogy közeledik a szállítási határidő, gyorsabb ciklusokban szeretnéd kijavítani az „utolsó hibát”, létrehozni az utolsó futtatható programot, stb. Ha húsz lépésből áll lefordítani a kódot, futtatni a telepítőcsomag készítőt stb., egyre idegesebb leszel, és buta hibákat fogsz ejteni.
Csak ezért váltott az utolsó cég, ahol dolgoztam, WISE-ról InstallShield-re: megköveteltük, hogy a telepítési folyamat képes legyen automatikusan, éjszakánként szkriptből futni az NT ütemezőből, de mivel a WISE nem akart futni éjszakánként az ütemezőből, ezért kidobtuk (a WISE kedves emberei biztosítottak afelől, hogy a legújabb változat már támogatja az éjszakánkénti parancsfájlból vezérelt fordításokat).
3. Készítesz napi fordításokat?
Ha használsz forráskövető rendszert, előfordulhat, hogy az egyik programozó véletlenül olyan kódot is feltölt a rendszerbe, amitől nem fordul le a szoftver. Például létrehozhat egy új forrásfájlt, amivel a saját gépén minden simán fordul, de elfelejti hozzáadni az új fájlt a forráskövető rendszer adatbázisához. Ígyhát boldogan – és hanyagul – kikapcsolja a gépét és hazamegy. Ezután persze már más sem fog tudni dolgozni, így ők is hazamennek, boldogtalanul.
A fordítási hiba előidézése annyira rossz (és szokásos) dolog, hogy érdemes napi fordításokat végezni, és ekkor előjönnek ezek a problémák. Nagy csapatoknál úgy biztosítható az efféle hibák azonnali javítása, hogy minden délután, például ebédidőben fut le a napi fordítás. Mindenki annyi módosítást végez a kódon ebéd előtt, amennyit csak tud. Mikor visszajönnek, a fordítás már befejeződött. Ha működött a dolog? Remek! Mindenki letölti a legfrissebb működő kódot, és mehet a munka tovább. Ha a fordítás során hiba lép fel, azt ki kell javítani, de addig is mindenki dolgozhat a saját gépén található, egy napos – de működő – kóddal.
Az Excel csapatban a következő szabályt vezettük be: aki fordítási hibát okozott a szoftverben, az lett a fordítási folyamat felügyelője, egészen addig, amíg valaki más nem hibázott. Ez egyrészt ösztönzött minket arra, hogy figyeljünk oda, és ne okozzunk fordítási hibát, másrészt mindenkinek lehetősége nyílt megismerni a szoftverfordítási folyamatot – hiszen mindenki sorra került.
A témáról többet olvashatsz A Napi Fordítás a barátod (angol nyelvű) cikkben.
4. Van hibakövető rendszered?
Nem érdekel, mit mondasz. Ha kódot fejlesztesz, akár magadban, akár csapatban, az ismert hibák listájának szervezett adatbázisa nélkül csak gyenge minőségű kódot tudsz előállítani. Sok programozó hiszi azt, hogy a hibalistát észben tudják tartani. Ez nonszensz. Én egyszerre csak két-három hibát tudok fejben tartani, s ezek következő reggelre, vagy a szállítási határidőhöz közeledve, a nagy rohanásban feledésbe merülnek. Mindenképpen szükséges formálisan nyomon követned a hibákat.
A hibakövetés lehet bonyolult, vagy egyszerű. Egy minimális, de használható hibakövető rendszerben minden hibának tartalmaznia kell az alábbi adatokat:
- a hiba reprodukálásához szükséges összes lépést,
- elvárt viselkedés,
- tapasztalt (hibás) viselkedés,
- kihez tartozik a hiba (kinek kell majd kijavítania),
- ki van-e javítva, vagy nincs.
Ha a hibakövető rendszer bonyolultsága az egyetlen, ami miatt nem követed a hibákat, készíts egy egyszerű, öt oszlopos táblát ezekkel a kötelező mezőkkel, és kezdd el használni.
A hibakövetésről bővebben a Fájdalommentes hibakövetés cikkben olvashatsz, angolul.
5. Új kód írása előtt javítod-e a hibákat?
A Microsoft Word for Windows legelső verzióját „halálmenet” projektnek tartották. Nem akart sose véget érni. Rendszeresen csúszott. Az egész csapat hihetetlenül sokat dolgozott, de a projekt újra és újra csúszott. A stressz elviselhetetlen volt. Aztán mikor évekkel később végül forgalomba hozták a terméket, a Microsoft elküldte az egész csapatot Cancunra nyaralni, majd leültek megkeresni magukban a hibát.
Azt vették észre, hogy a projektmenedzserek annyira ragaszkodtak az „ütemtervhez”, hogy a programozók egyszerűen átrohantak a kódolási folyamaton, hihetetlenül rossz minőségű kódot írva, mivel a hibajavítás nem volt része a formális ütemtervnek. Meg sem próbálták alacsonyan tartani a hibaszámot. Pont az ellenkezője történt. Az a hír járja, hogy egy programozónak, akinek az lett volna a feladata, hogy írjon kódot arra, hogy kiszámolja egy sor magasságát, egyszerűen „return 12;”-t írt, és várta, hogy jöjjön a hibajelentés, hogy a függvény nem működik mindig helyesen. Az ütemterv a tulajdonságok egyszerű listája volt, amely arra várt, hogy hibává váljon. A boncolás után erre, mint a „végtelen hiányosság modszertana”-ként hivatkoznak.
A hiba kijavítására a Microsoft egyetemlegesen bevezette a „nulla hiányosság módszertant”. A cég számos programozója csak nevetett ezen, mivel úgy hangzott, mintha lejjebb tudnák szorítani a hibaszámot egy felsővezetői döntéssel. Valójában a „nulla hiányosság” azt jelentette, hogy a legnagyobb prioritás mindenkor a hibák eltávolítása, bármilyen új kód írása előtt. Íme, ezért:
Általánosságban minél többet vársz a hiba kijavításával, annál költségesebbé válik (időben és pénzben) a javítás.
Ha például, elütést vagy szintaktikai hibát vétesz, amit a fordító észrevesz, a javítás alapvetően triviális.
Ha olyan hiba van a kódban, amit az első próbafutásnál észreveszel, semeddig sem tart kijavítani, mivel a kód még frissen az eszedben van.
Ha egy olyan kódban találsz hibát, amelyet néhány nappal ezelőtt írtál, eltart egy ideig, amíg megtalálod, de mikor újraolvasod a saját kódodat, minden eszedbe fog jutni, és ésszerű időn belül ki tudod javítani a hibát.
De ha olyan kódban találsz hibát, amelyet néhány hónappal ezelőtt írtál, már valószínűleg sokmindent elfelejtettél arról a kódról, és sokkal nehezebb lesz kijavítani. Addigra elképzelhető, hogy már valaki más kódját javítod, aki Arubán tölti a szabadságát. Ebben az esetben a hibajavítás a kutatáshoz hasonlít: lassúnak, módszeresnek és aprólékosnak kell lenned, és nem tudhatod, hogy meddig tart felfedezni a gyógymódot.
És ha olyan kódban találsz hibát, amely már forgalomba került, akkor hihetetlenül nagy költségeknek nézel elébe a hibajavítás során.
Ez az első ok arra, hogy azon nyomban javítsd a hibákat: kevesebb időt vesz igénybe. Van egy másik ok, amely azon a tényen alapszik, hogy könnyebb megjósolni, meddig tart az új kód megírása, mint azt, hogy meddig tart egy meglévő hiba kijavítása. Ha például arra kérlek, hogy jósold meg, meddig tart egy lista sorbarendezését megírni, egész jól meg tudod becsülni. Ám ha arra kérlek, hogy jósold meg, hogy meddig tart kijavítani a kódod, ami nem megy, ha Internet Explorer 5.5 van installálva, még csak meg sem tudod becsülni, mivel nem tudod (definíció szerint), hogy mi okozza a hibát. Eltarthat három napig a megtalálása, de tarthat két percig is.
Ez azt jelenti, hogy ha az ütemtervedben számos kijavítatlan hiba szerepel, az ütemterv megbízhatatlan lesz. Ám ha minden ismert hibát kijavítottál, és csak új kód írása van benne, az ütemterv meglepően pontos lesz.
Még egy jó dolog van a hibaszám nullán tartásában, mégpedig az, hogy gyorsabban tudsz reagálni a versenytársak lépéseire. Vannak programozók, akik ezt úgy mondják, hogy a terméket folyamatosan forgalmazásra kész állapotban kell tartani. Aztán, ha egy versenytársad egy vadonat új tulajdonsággal rukkol elő és elcsábítja az ügyfeleidet, egyszerűen kifejlesztheted ugyanazt a funkciót, és azonnal szállíthatod a programot, anélkül, hogy számos összegyűlt hibát kéne kijavítanod először.
6. Van jól karbantartott ütemezésed?
Ez elvezet az ütemtervhez. Ha a kódod egyáltalán fontos az üzlethez, számos oka van az üzletnek arra, hogy tudja, mikor lesz a kód kész. A programozók hírhedten morcosak az ütemterv készítésével kapcsolatban. „Kész lesz, mikor kész lesz” – mondják az üzletembereknek.
Sajnos ez nem elegendő. Túl sok tervezési döntést kell meghozni az üzlet érdekében, jóval a szállítás előtt: demók, szakmai bemutatók, reklámok, stb. Ezekhez elengedhetetlen a naprakész ütemterv létezése.
A másik életbevágó dolog az ütemtervvel kapcsolatban az, hogy kikényszeríti annak eldöntését, hogy milyen tulajdonságok kerüljenek a termékbe, és rákényszerít arra, hogy fogd a legkevésbé fontosakat, és vágd ki ezeket. Így nem kap el a featuritis nevű betegsége (azaz nem lesz a program tele haszontalan és átgondolatlan funkciókkal).
Az ütemterv betartása nem olyan nehéz. Olvasd el a Fájdalommentes ütemezés a szoftverfejlesztésben című cikkemet, ami egy egyszerű módszert nyújt jó ütemterv készítéséhez.
7. Van specid?
A specik írása olyan, mint a fogselyem használata: mindenki egyetért abban, hogy hasznos, de senki sem csinálja.
Nem tudom, miért van ez így, de valószínűleg azért, mert a legtöbb programozó utál dokumentumotkat írni. Végeredményként, mikor egy csak programozókból álló csapat támad meg egy problémát, jobban szeretik a megoldásukat kódban kifejezni, mind dokumentumban. Inkább ugranak bele, és írnak kódot, mielőtt specifikációt írnának.
A tervezési fázisnál ha felismered a problémákat, egyszerűen, néhány sor átírásával javítani tudod. Ha egyszer már meg van írva a kód, a problémák javításának költsége drámaian megnő mind emócionálisan (az emberek nem szeretnek kódot kidobni), mind időben, tehát lesz egy ellenállás a hibák tényleges kijavítása ellen. Arról a szoftverről, amely nem speci alapján készült, rendszerint tervezési hibák derülnek ki, és az ütemterv tarthatatlan lesz. Úgy tűnik, ez volt a problémája a Netscape-nek, mikor az első négy verzió olyan szemétté duzzadt, hogy a vezetés bután úgy döntött, hogy kidobják az egész kódot, és újraírják. Aztán ugyanezt a hibát megint elkövették a Mozillával, létrehozva egy szörnyet, amely kikerült az irányítás alól, és több év kellett ahhoz, hogy elérjenek az alfa állapotba.
A saját kedvenc elméletem erre az, hogy ez a probléma megoldható, ha a programozókat ránevelik arra, hogy ne vonakodjanak az írástól. Például el lehet küldeni őket egy intenzív írói kurzusra. Másik megoldás: felbérelni okos programmenedzsereket, akik megírják a program specifikációját. Bármelyik esetben megkövetelendő a „nincs kód speci nélkül” egyszerű szabály.
Tanulj meg mindent a speci írásról a négy részes írásomból (angol nyelvű).
8. A programozók nyugodt körülmények között dolgozhatnak?
Terjedelmesen dokumentált hatékonyságbeli előnyök származnak abból, ha helyet, csöndet és egyedüllétet biztosítunk a szellemi munkaerőnek. Ezeket a termelékenységi előnyöket a Peopleware, a klasszikus szoftvermenedzsment könyv részletesen taglalja.
Íme, a probléma. Mindannyian tudjuk, hogy a szellemi munkások a legjobban úgy tudnak dolgozni, hogy „elmerülnek” a munkában, vagy ahogy másként nevezik, „zónába kerülnek”, ahol teljesen koncentrálni tudnak a munkára, és teljesen kikapcsolják a környezetüket. Elvesztik az időérzéküket, és remek dolgokat készítenek abszolút koncentrációval. Ilyen, mikor a produktív munkájukat végzik. Írók, programozók, tudósok, sőt, még a kosárlabda játékosok is azt mondják, hogy zónában vannak.
A baj az, hogy zónába kerülni nem könnyű. Ha megméred, olyan 15 percbe kerülhet, mire teljes termelékenységgel tudsz dolgozni. Néha, ha már fáradt vagy, vagy már sok kreatív munkát végeztél aznap, egyszerűen nem tudsz eljutni a zónába, és azzal töltöd a nap fennmaradó részét, hogy babrálsz, webet böngészel, Tetris-t játszol.
A másik baj az, hogy nagyon egyszerűen kikerülsz a zónából. Zaj, telefoncsörgés, ebédelés, az az öt perc, amíg leugrasz a kávézóba, vagy a munkatársak megszakításai – különösen a munkatársak megszakításai – kiütnek a zónából. Mikor egy munkatársad feltesz egy kérdést, egy perc megszakítást okoz, de téged annyira kiüt a zónából, hogy fél óráig tart, mire újra belelendülsz, és az általános termelékenységed súlyos károkat szenved. Ha egy hangos, nagy légterű környezetben vagy &ndash olyanban, amelyeket azok a kávéfüggő dotkomosok szeretnek – mikor a marketingesek kiabálnak a telefonba közvetlenül programozók mellett, a produktivitásod mélyrepülésbe kezd, mivel a szellemi munkaerő időről időre meg van szakítva, és sosem tudnak a zónába kerülni.
A programozóknál ez főleg nehéz. A produktivitás nagyban függ a rövidtávú memóriában tárolt sok apró részlettel való zsonglőrködéstől. Bármilyen megszakítás az összes részlet szétesését okozhatja. Mikor újra kezded a munkát, már nem emlékszel az összes részletre (mint a használt helyi változónevek, vagy hogy hol implementáltad azt a keresőalgoritmust), és újra meg kell szerezned ezeket az információkat, ez lelassít, míg újra fel nem tudod venni a sebességet.
Íme egy kis egyszerű algebra: mondjuk (ahogy a tények alapján kiderült), hogy ha megszakítunk egy programozót, még ha csak egy percre is, valójában 15 percre kiesik a ritmusból. A példa kedvéért vegyünk két programozót, Józsit és Márkot, két, egymás melletti nyitott fülke lakóját egy szokványos Dilbert-féle marhatelep típusú irodában. Márk nem emlékszik a strcpy(3) függvény Unicode-os változatának nevére. Ki tudná keresnia fejlesztői környezet súgójából – ez 30 másodpercig tartana – de megkérdezheti Józsit is, ami csak 15 másodperc. Mivel Józsi mellett ül, megkérdezi. Márk megzavarja Józsit, ezzel Józsi veszít 15 percet (hogy nyerjen Márknak 15 másodpercet).
Most helyezzük őket különálló irodába, falakkal és ajtókkal. Ebben az esetben, ha Márk nem emlékszik a függvény nevére, még mindig kinézheti a súgóból, ami 30 másodperc, vagy megkérdezheti Józsit, ami most már 45 másodperc, és ebben benne van a felállás (nem egy könnyű művelet figyelembe véve a programozók átlagos fizikai erőnlétét!). Így hát Márk inkább a súgóhoz fordul. Így Márk veszített 30 másodpercet, de nyertünk Józsinak 15 percet! Aha!
9. Az elérhető legjobb segédeszközöket használjátok?
Fordítást igénylő programkódot írni az egyik utolsó dolog, amelyet nem lehet azonnal egy mezei, otthoni számítógépen megtenni. Ha a fordítási folyamat több mint néhány másodperc, akkor a legújabb és legjobb számítógép vásárlása megoldja a problémát. Ha a fordítás tovább tart akár csak 15 másodpercnél, a programozók unatkozni fognak, míg a fordító fut, és inkább elkezdik olvasni az Index-et, ami beszippantja őket, és órákat veszítenek a produktivitásukból.
GUI hibajavításra egy képernyőt fájdalmas használni, ha nem lehetetlen. Ha GUI kódot írsz, két monitor számos dolgot sokkal egyszerűbbé tesz.
A legtöbb programozó néha bittérképet kell kezeljen, ikonokhoz és eszköztárakhoz, és a legtöbb programozónak nincs jó bittérképszerkesztője. Erre a Microsoft Paint-et használni vicc, de a legtöbb programozó mégis kénytelen ezzel beérni.
Az utolsó munkahelyemen rendszeresen küldött nekem a rendszeradminisztrátor egy automatikus spam-et arról, hogy több, mint … ezt kapd ki … 220 megabájtot használok a szerver merevlemezén. Rámutattam, hogy manapság a merevlemezek árait véve ez a hely lényegesen kevesebb, mint a WC papír, amit elhasználok. A könyvtáram kipucolására szánt akár 10 perc is mérhetetlen elpocsékolása a termelékenységemnek.
A legnyerőbb fejlesztőcsapatok nem kínozzák a programozóikat. Még a kevésbé hatékony eszközök használatából adódó legkisebb csalódottság is összeadódik, a programozót rosszkedvűvé és elégedetlenné téve. És egy rosszkedvű programozó nem hatékony programozó.
Az egészhez még hozzájön az, hogy a programozókat könnyű a legszuperebb, legújabb dolgokkal ellátva megvesztegetni. Ez sokkal olcsóbb módja annak, hogy munkára fogd őket, mint a versenyképes fizetés!
10. Vannak tesztelőid?
Ha a csapatodban nincsenek dedikált tesztelők, minden két-három programozóra legalább egy, akkor vagy hibás terméket fogsz kiszállítani, vagy arra pazarlod a pénzedet, hogy óránként $100-ba kerülő programozókat használsz olyan munkára, amelyet óránként $30-ért elvégezne egy tesztelő. A tesztelőken spórolni annyira nem kifizetődő, hogy egyszerűen nem hiszem el, hogy más emberek ezt nem veszik észre.
Olvasd el az Legfontosabb öt (hibás) ok, amiért nincsenek tesztelőid cikket (angolul).
11. Íratsz kódot a felvételi elbeszélgetésen?
Felbérelnél egy varázslót anélkül, hogy megkérnéd, mutasson néhány mágikus trükköt? Természetesen nem.
Felbérelnél egy szakácsot a lakodalmadra anélkül, hogy megkóstolnád az ételt? Kétlem (kivéve, ha az éppen Margit nénéd, aki örökre megutálna, ha nem engednéd, hogy felszolgálja a „híres” aprított májtortáját).
Mégis, minden nap, programozókat vesznek fel jó benyomást keltő önéletrajzuk alapján, vagy mert az interjút készítő élvezte a velük való beszélgetést. Esetleg néhány keresztkérdés alapján („Mi a különbség a CreateDialog() és a DialogBox() között?”), amelyek könnyen megválaszolhatók a dokumentáció átnézése után. Téged nem az érdekel, hogy betanult-e ezer keresztkérdést a programozással kapcsolatban, hanem az, hogy tud-e kódot írni. Vagy, még rosszabb, amolyan „AHA!”-jellegű kérdéseket kérdeznek: olyanokat, amelyek egyszerűek, ha tudod a megoldást, de ha nem, akkor lehetetlen a megfejtést kitalálni.
Kérlek, egyszerűen hagyd ezt abba. Tégy azt egy interjú alatt, amit akarsz, de irass kódot a jelölttel. További tanácsokért olvasd el a Interjúztatás – Gerilla módra című írásomat.
12. Végzel folyosói használhatósági tesztet?
A folyosói használhatósági teszt az, amikor megfogod a folyosón első szembejövő embert, és rákényszeríted, hogy próbálja meg használni azt a programot, amit épp írtál. Ha ezt megcsinálod öt emberrel, kiderül a kódod használhatósági problémáinak 95%-a.
A jó grafikus felhasználói felület (GUI) tervezése nem annyira nehéz, mint amennyire gondolod, de létfontosságú, ha azt szeretnéd, hogy az ügyfeleid szeressék és megvegyék a termékedet. Elolvashatod az inyenesen elérhető online könyvemet a felhasználói felület tervezésről, ez egy gyorstalpaló, programozóknak.
Ám a legfontosabb dolog a felhasználói felületekkel kapcsolatban az, hogy ha bemutatod a programot egy maréknyi embernek (valójában öt-hat elegendő), gyorsan felfedezed az emberek a felülettel kapcsolatos legnagyobb problémáit. Olvasd el Jakob Nielsen cikkét a dolog miértjének magyarázatáért. Még ha az UI tervezői tudásod hiányos is, amíg rákényszeríted magad a folyosói használhatósági tesztekre – ezek nem kerülnek semmibe –, a felületed sokkal, de sokkal jobb lesz.
Négy módszer a Joel-teszt használatához
- Értékeld a saját szoftvercégedet, és mondd el, hogy szerepelt, így tudok pletykázni.
- Ha te vagy a programozó csapat vezetője, használd ezt a listát arra, hogy biztos legyél arra, hogy a csapatod a lehető legjobban dolgozik. Ha 12 ponttal kezdesz, hagyd békén a csapatot, és a teljes idődet fordítsd arra, hogy az üzletemberek ne zavarják meg őket.
- Ha épp el akarod dönteni, hogy elfogadsz-e egy programozói állást, kérdezd meg leendő munkáltatódat, hogy értékelné magát a teszten. Ha túl alacsony, légy biztos abban, hogy meglesz a felhatalmazásod ezenek a problémáknak az orvosolásához. Egyébként csalódott leszel, és nem hatékony.
- Ha befektető vagy, és körültekintésből meg akarod ítélni egy programozó csapat értékét, vagy ha a szoftvercéged egy másikkal kíván egyesülni, ez a teszt jó ökölszabálynak.