Joel on Software - Joeli test: 12 sammu parema koodini

Kas teate, mis on SEMA? See on üpris esoteeriline süsteem tarkvarameeskonna headuse mõõtmiseks. … Oot-oot, ärge praegu minge sellele lehele! Teil kulub hea mitu aastat üksnes kogu selle kraami mõistmiseks. Pakun teile hoopiski oma vastutusvaba ja veidi „ülenurga“ testi, mille parim omadus on see, et tema täitmiseks kulub vaid kaks-kolm minutit. Kokkuhoitud aega saate kulutada oma äranägemisel, näiteks meditsiinikoolis õppimiseks.

Joeli testi parim omadus on see, et te saate igale küsimusele kergesti ja kiiresti jaatavalt või eitavalt vastata. Teil pole tarvis hinnata päevas kirjutatavate koodiridade arvu või vigu * inflection-point kohta. Iga jaatav vastus annab teie meeskonnale ühe punkti. Ärge siiski kasutage Joeli testi hindamaks, kas teie kirjutatud tuumajaama-tarkvara on töökindel ja turvaline.

12 punkti on eeskujulik tulemus, 11 rahuldav, kuid 10 ja vähem punkti viitab tõsistele probleemidele teie firmas. Tõsi, enamik tarkvaratootjaid töötab kahe- või kolmepunktilise skooriga – ning vajab tõsist abi, sest sellised kompaniid nagu Microsoft käivad ööpäevaringselt 12 punkti režiimil.

Loomulikult pole ülaltoodud ainukesed edu või läbikukkumist määravad tegurid: näiteks, kui teie suurepärane tarkvarameeskond töötab sellise toote kallal, mida keegi ei taha, siis ... noh... inimesed ei hakka ikkagi seda tahtma. Ja vastupidi, on võimalik, et mõni * “gunslingers” meeskond ei saa Joeli testis ühtki punkti, kuid suudab ometigi produtseerida võrreldamatut, revolutsioonilist tarkvara. Ometigi – ülaltoodule vastu vaidlemata – kui te vastasite testis 12 korda jaatavalt, siis on teil distsiplineeritud, pidevalt kvaliteetset toodangut andev meeskond.

1. Kas te kasutate * source control?
Ma olen kasutanud kommertsiaalseid * source control pakette, ja olen kasutanud vabavarana levitatavat paketti CVS, ning jõudnud järeldusele, et CVS on kena. Kui teil aga * source control puudub, näete hirmsat ja tagajärjetut vaeva programmeerijate koostöö korraldamisel. Programmeerija ei tea, mida ta kolleegid on teinud. Vigaseid lahendusi pole lihtsasti (ja vahel üldsegi) võimalik tagasi võtta. * Source control meeldiva kõrvalefektina on projekti kood * checked out iga programmeerija kõvakettal – ma pole kuulnud ühestki * source control kasutavast projektist, kus märkimisväärne hulk koodi oleks mõne õnnetusjuhtumi läbi kaotsi läinud.

2. Kas te saate töötava koodi valmis üheainsa sammuga?
See tähendab: mitu sammu teil kulub viimasest lähtetekstide seisust töötava, tarbijale antava * build saamiseks? Heal meeskonnal on olemas üks ja ainus skript, mis nullist alustades teeb täieliku * checkout, kompileerib kogu koodi uuesti, teeb valmis kasutatavate keelte, #ifdef-kombinatsioonide ja muude tingimuste poolest erinevad .EXE-failide versioonid, koostab installeerimispaketi ning teeb sellest lõpptulemuse – CD-ROM-i kujutise, võrgulehe allalaadimiseks, või muu vajaliku.

Kui see protsess koosneb mitmest sammust, olete oma töösse lisanud veel ühe vigade allika. Ning – mida ligemale jõuab üleandmise tähtaeg, seda enam soovite, et teil oleks kiire “viimase” vea parandamise, rekompileerimise jne. tsükkel. Kui koodi kompileerimise, installatsiooniprogrammi käivitamise jne. protsess koosneb kahekümnest sammust, ajab see teid hulluks ning te hakkate rumalaid vigu tegema.

Pelgalt sel põhjusel võeti minu viimases töökohas WISE’i asemel kasutusele InstallShield: me nõudsime, et installatsiooni tegemise protsessi saaks öösiti, automaatselt, etteantud skripti järgi käivitada NT plaanur. WISE polnud võimeline jooksma NT plaanuri alt, niisiis pidime temast loobuma. (WISE’i töötajad on mind lahkesti teavitanud, et nende viimane toode toetab öiseid * build seansse).

3. Kas te teete igapäevaseid * builds?
* Source control-i kasutades juhtub aeg-ajalt, et mõni programmeerija kogemata * checks in midagi, mis * breaks the build. Näiteks lisab keegi uue lähtetekstifaili ja tema arvutis kompileerub kõik imeliselt, kuid ta unustab selle faili * code repository-le lisada. Hajameelne ja õnnelik, paneb süüdlane oma masina lukku ja läheb koju. Teistel pole nüüd aga enam võimalik tööd teha ning nemadki peavad koju minema – ainult et õnnetult.

* Breaking the build on nii halb (ja nii üldlevinud) nähtus, et igapäevaste * builds tegemine aitab tublisti töökatkestusi vältida. Suurtes meeskondades võib katkestuste kiireks avastamiseks teha * daily build igal pärastlõunal – näiteks lõunaajal. Igaüks * does as many checkins as possible enne lõunat. Kui lõunalt naastakse, on * build valmis. Kui see õnnestus, on kõik parimas korras: igamees * checks out koodi viimase versiooni ja läheb oma tööga edasi. Kui aga * build ebaõnnestus, parandab süüdlane vead ning samaaegselt saavad teised programmeerijad jätkata tööd koodi eelviimase, * unbroken (kompileeruva) versiooniga.

Exceli-meeskonnas oli meil reegliks, et süüdlane (kes * broke the build) sai “karistuseks” kohustuse kanda hoolt järgmiste * build eest, kuni leidus keegi, kes järgmisena * broke it. See sundis inimesi olema hoolikamad, et mitte * to break the build, ning samas andis loomuliku võimaluse kaasata kõik programmeerijad * build process-i, nii et igaüks saaks aimu seal toimuvast.

4. Kas te kasutate vigade andmebaasi?
Ja mind ei huvitagi, mis teie selle kohta arvate. Kui te toodate koodi – ükspuha, kas suure meeskonna koosseisus või ihuüksi – ja ei kasuta andmebaasi, mis säilitaks informatsiooni kõigi teadaolevate vigade kohta, siis te toodate ebakvaliteetset koodi. Paljud programmeerijad arvavad, et nad suudavad vigade loetelu meeles pidada. See on jama. Mina ei suuda korraga mäletada rohkem kui kaks-kolm viga ning järgmiseks hommikuks (või üleandmistähtaja-eelses palavikulises tegevuses) on nad hõlpsasti ununenud. Te lihtsalt peate vigade üle mingil formaalsel viisil arvet pidama.

Vigade andmebaasid võivad olla keerulised või lihtsad. Minimaalne kasulik vigade baas peab iga vea kohta säilitama järgmist informatsiooni:

Kui vigade jälgimise tarkvara ülim keerukus on ainus, mis teid seni on hoidnud seda kasutamast. siis tehke ülaltoodud andmeid sisaldav lihtne viieveeruline tabel ja hakake seda kasutama..

5. Kas te parandate vead enne uue koodi kirjutamisele asumist?
Microsoft Word for Windows esimese versiooni projekt on tuntud kui * "death march" projekt. See kestis igavesti. See venis ja venis. Kogu meeskond töötas ööpäevaringselt... tähtajad nihkusid taas, ja uuesti ja ikka jälle... töötajate stress oli kirjeldamatu. Kui see neetud Word ükskord (planeeritust aastaid hiljem) valmis sai, saatis Microsoft kogu meeskonna puhkusele, ja võttis põhjuste otsimiseks aja maha.

Mis selgus? Projektijuhid tähtsustasid „ajagraafikust kinnipidamist“ niivõrd, et programmeerijad olid sunnitud kirjutama koodi nii-öelda jooksu pealt – ja seega produtseerisid eriti halba koodi. Asjaolu, et vigade parandamist polnud ametlikus ajaplaanis ette nähtud, ei aidanud koodi kvaliteedile kuidagi kaasa. Vigade hulga kahandamiseks ei võetud mingeid meetmeid, pigem vastupidi. Räägitakse, et üks programmeerija, kes pidi kirjutama tekstirea kõrguse arvutamise funktsiooni, kirjutas lihtsalt „return 12,“ ning jäi ootama teadet selle kohta, et tema funktsioon ei tööta alati õigesti. Nii kujutas ajagraafik endast programmi omaduste loetelu, mis vaid ootasid endi vigadeks muutumist. Post-mortem sai selline käitumine nimeks „lõpmatu arvu vigade meetod“ ("infinite defects methodology").

Probleemi lahendamiseks võttis Microsoft üldiselt kasutusele „null-vea-meetodi“ ("zero defects methodology"). Paljudele programmeerijatele tegi see nalja, sest kõlas nii, justkui oleks juhtkond arvanud, et suudab vigade arvu kahandada administratiivsete jõupingutuste läbi. Tegelikult on „null-vea-meetodi“ mõte selles, et igal ajahetkel tuleb avastatud vead likvideerida enne uue koodi kirjutamist. Miks?

Üldiselt, mida kauem te ootate enne vea parandamist, seda kulukamaks (nii ajaliselt kui rahaliselt) see parandamine läheb.

Näiteks trükivea või kompilaatori avastatud süntaksivea parandamine on üldiselt triviaalne.

Kui te avastate vea oma koodist selle esimesel käivitamisel, suudate selle parandada peaaegu ajakuluta, sest kogu kood on teil veel värskelt meeles.

Kui te leiate vea mõne päeva eest kirjutatud koodis, kulutate veidi aega tema lokaliseerimiseks, kuid koodi lugedes tuleb teile veel meelde, mis seal toimub, ning suudate vea parandada täiesti mõistliku aja jooksul.

Kui aga leiate vea mõne kuu eest kirjutatud koodis, olete tõenäoliselt sellest palju üksikasju unustanud (või ei mäleta üldse, mis seal toimub) ja parandamine on sel juhul palju raskem. Lisaks võib selleks ajaks teid olla pandud kellegi teise kirjutatud koodi parandama, autor aga on läinud puhkusele – missugusel juhul on vigade parandamine justkui teadus: te peate töötama aeglaselt, metoodiliselt ja täpselt. Ning te ei saa ennustada, kui kaua ravi võib kesta.

Lõpuks, kui leiate vea juba tarnitud koodist, olge valmis kandma ettekujutamatuid kulutusi selle parandamiseks.

Üks vigade kohese parandamise eelis on niisiis see, et nii saame aega kokku hoida. Teine eelis tuleneb asjaolust, et kergem on hinnata uue koodi kirjutamiseks kuluvat aega kui vigade parandamise kestust. Kui ma küsiksin teilt, kui kaua kulutate järjestamisprogrammi kirjutamiseks, saaksin teilt üsna kiiresti üsna tõepärase hinnangu. Kui ma küsiksin, kui kaua kulub selle vea parandamiseks, mis takistab teie koodil töötamast, kui arvutisse on installeeritud Internet Explorer 5.5, ei suudaks te ajakulu kohta isegi midagi arvata, sest (definitsiooni kohaselt) te ei tea vea põhjust. Teil võib selle avastamiseks kuluda kolm päeva ... või kaks minutit.

Niisiis, kui teie ajaplaani järgi jääb palju vigu koheselt parandamata, pole see plaan usaldatav. Kui kõik teadaolevad vead on parandatud ja plaanis on vaid uue koodi kirjutamine, on teie hinnangud oluliselt täpsemad.

Vigade arvu nullile lähendamine toob kaasa meeldiva kõrvalefekti: te saate konkurentide ettevõtmistele kiiresti reageerida. Mõned programmeerijad mõtlevad sellest kui produkti pidevast tarnimisvalmis hoidmisest. Kui teie võistleja lisab oma programmile mingi eriti popi omaduse, mis võib teie tarbijaid üle meelitama hakata, saate ka teie ainult sellesama omaduse realiseerimise järel oma toote uue versiooni turule tuua, ilma et teil oleks tarvis kuhjunud vigade ränga koormaga võidelda.

6. Kas teil on olemas aktuaalne töögraafik?
Nii jõudsimegi ajagraafikute juurde. Kui teie kirjutatav kood üldse firmale midagi väärt on, siis on ilmselt olemas mitmeid põhjusi, miks juhtkonnal on tähtis teada, kuidas selle kirjutamisega lood on. Programmeerijad on teadaolevalt väga hellad igasugu ajaplaanide suhtes. „Ma saan selle valmis siis, kui ma ta valmis saan“, kähvavad nad tüüpiliselt projektijuhile.

Kahjuks selline meetod eriti ei tööta. Firma äripool peab tublisti enne koodi lõplikku valmimist paika panema programmi demonstratsioonide ja esitlemiste ajad, reklaamide ajad ja mahud jne. Ning ainus viis sellega hakkama saada on teha ajagraafik ja hoida seda tegelikkusega vastavuses.

Korralik töögraafik sunnib teid ka otsustama, missugused programmi omadused realiseerida, ning seejärel valima välja vähima tähtsusega omadused ja need realiseerimata jätma. Nii väldite nakatumist haigusse nimega featuritis (tuntud ka kui * scope creep).

Ajaplaani pidamine pole ületamatult raske. Lugege mu artiklit Painless Software Schedules, kus kirjeldan heade ajagraafikute tegemise lihtsat viisi.

7. Kas teil on olemas spetsifikatsioon?
Spetsifikatsioonide kirjutamine on justkui * flossing: kõik teavad, et see on Hea Asi, kuid keegi ei tee seda.

Ma pole päris kindel, miks see nii on, kuid arvan, et põhjust tuleb otsida enamiku programmeerijate sügavast vastumeelsusest igasuguse dokumentatsiooni kirjutamise suhtes. Ainult programmeerijatest koosnev meeskond eelistab niisiis oma lahendusi väljendada koodis, mitte dokumentides. Nad hüppavad rõõmuga tundmatus kohas vette ja kirjutavad koodi enne spetsifikatsiooni.

Disainietapil avastatud probleemi saate tüüpiliselt lahendada mõne tekstirea muutmisega disainidokumendis. Juba kirjutatud koodi muutmise hind on tublisti kõrgem: nii emotsionaalselt (sest kes ikka tahab oma koodi lihtsalt minema visata) kui ka ajaliselt. Niisiis tekib sel etapil probleemide lahendamisele mõningane vastuseis. Spetsifikatsioonideta loodud tarkvara kipub olema kehva disainiga ja väljub tihti kontrolli alt. Nii tundus olevat Netscape-iga, mille esimesed 4 versiooni kasvasid selliseks segapudruks, et juhtkond tegi rumala otsuse * stupidly decided heita kogu senise koodi kõrvale ja alustada otsast peale. Ja siis kordasid nad sama viga Mozillaga, luues kontrolli alt väljunud koletise, millel kulus mitu aastat alfa-küpsuseni jõudmiseks.

Mu lemmikteooria ütleb, et seda probleemi saab lahendada programmeerijatele dokumentatsiooni kirjutamist õpetades, saates nad näiteks mõnele vastavale intensiivkursusele * an intensive course in writing. Teisalt võiks leida andekaid mänedžere, kes suudaksid spetsifikatsiooni kirjutada. Igatahes peaksite igati järgima lihtsat reeglit „ei ridagi koodi spetsifikatsioonita“.

8. Kas programmeerijatele on loodud vaikne ja rahulik töökeskkond?
Vaimse töö tegijatele ruumi, vaikuse ja privaatsuse võimaldamisest saadav tootlikkuse kasv on üpris hästi teada ning sellest kirjutab põhjalikult klassikaline tarkvaratootmise juhtimisele pühendatud teos Peopleware.

Milles on probleem? Me kõik teame, et vaimse töö tegijad töötavad kõige paremini, kui „nad saavad joone peale“, „kui neil tuleb vaim peale“ või kuidas seda loovusseisundit siis ka nimetataks. Siis on nad oma tööst täielikult hõivatud ja ümbrusest täiesti välja lülitunud. Neil kaob ajataju ning sellises täieliku kontsentratsiooni seisundis loovad nad suurepäraseid asju. Kogu looming pärineb sellest seisundist. Kirjanikud, programmeerijad, teadlased – ja miks mitte ka korvpallurid – võivad teile loovusehetkedest rääkida.

Kuid täieliku kontsentratsiooni saavutamine pole kerge. Seda on küll keeruline mõõta, kuid näib, et „vaimu pealetulek“ võtab oma 15 minutit. Alles siis hakkame täie võimsusega tööle. Mõnikord oleme haiglased, või sel päeval juba kenakese hulga tööd ära teinud ning end tühjaks pigistanud, ning saadame päeva õhtusse kolleegide juures juttu ajades, veebis kolades või tetrist mängides.

Veel halvem on see, et vaimu pealt ära ajada on imekerge. Juhuslik müra, telefonikõne, lõuna, poodi kohvi järele minek ja kolleegide katkestused – eriti kolleegide katkestused toovad teid reaalsesse maailma tagasi. Kui kolleeg küsib teilt lihtsa küsimuse, millele vastamiseks kulutate vaid minuti, kuid tööle pühenduda suudate alles poole tunni möödudes, siis on teie tootlikkus sel päeval tõsise löögi saanud. Suures lärmakas saalis, nagu mitmed dotcom-firmad armastavad luua, koos mänedžeridega, kes programmeerijate kõrva ääres järelejätmatult telefonidesse karjuvad, ei suuda enamik loovtöötajaid kunagi täielikult kontsentreeruda ja nende tööviljakus jääb madalaks.

Programmeerijate juhtum on eriti raske. Programmeerija tootlikkus sõltub tema võimest üheaegselt tegelda suure hulga lühiajalises mälus hoitavate pisiasjadega. Igasugune katkestus lõhub nende detailide vahelised seosed justkui kaardimajakese. Töö juurde tagasi pöördudes ei mäleta programmeerija enam mitmeid detaile (näiteks lokaalsete muutujate nimesid või seda, kui kaugele ta mullimeetodi realiseerimisega jõudis), niisiis peab ta need kusagilt järele vaatama, mis raiskab aega.

Toome arvnäite. Oletame (nagu vaatlused ja kogemused kipuvad näitama), et kui katkestame programmeerijat kas või minutiks, rikume tema järgneva 15 minuti töö. Olgu Peeter ja Paul kaks programmeerijat, kes töötavad tüüpilise Dilberti-farmi kahes kõrvutises lahtises boksis. Peeter ei mäleta strcpy Unicode-i versiooni nime. Ta võiks selle ise üles otsida (kulutades 30 sekundit) või küsida Paulilt (mis võtab 15 sekundit). Istudes Pauli kõrval, küsib ta funktsiooni nime loomulikult Paulilt. Paul ärkab oma tööst, vastab ja kaotab järgmised 15 minutit „joone peale“ tagasisaamisega ... säästes Peetri 15 sekundit.

Oletame nüüd, et meie programmeerijad istuvad kumbki oma päris toas, seinte ja ustega ja puha. Kui Peetrile ei tule funktsiooni nimi kuidagi meelde, võib ta selle ise helbist järele vaadata (sellele kulub ikka 30 sekundit) või minna ja küsida Paulilt (see võtab nüüd 45 sekundit ning sisaldab püstitõusmise operatsiooni, mis programmeerijate füüsilist vormi arvestades võib mittetriviaalne operatsioon olla). Niisiis loeb Peeter helpi. Niisiis kaotab Peeter 30 sekundit (tegelikult 15), kuid meil õnnestus kokku hoida 15 minutit Pauli tööaega. Vaat nii!

9. Kas kasutate parimaid saadaolevaid programmeerimisvahendeid?
Kompileeritava keele koodi kirjutamine on üks viimaseid asju, mida ei saa keskmises koduarvutis teha ühe silmapilgu vältel. Kui projekti kompileerimisele kulub rohkem kui mõni sekund, peaksite aja oluliseks kokkuhoiuks muretsema kõige uuema ja kiirema arvuti. Sest kui kompilaator töötab kas või 15 sekundit, tüdineb programmeerija ootamisest ja käivitab mõne paralleelprotsessi, hakates näiteks lugema * The Onion, mis haarab ta endasse ning nullib mitme tunni töö.

Graafilise kasutajainterfeisi (GUI) koodi silumine ainsal monitoril on piinavalt raske või üldsegi võimatu. GUI kirjutamisel teeb teine monitor elu palju kergemaks.

Paljud programmeerijad peavad vahetevahel looma * bitmaps ikoonide või tööriistaribade jaoks, ja enamikul programmeerijatest pole selleks sobivat tööriista. Microsoft Paint-i kasutamine ikoonide joonistamiseks on halb nali, kuid sellega peavad paljud programmeerijad leppima.

Mu viimases töökohas saatis süsteemiadministraator mulle pidevalt automaatset rämpsposti teemal, et ma raiskavat enam kui – kujutage ette – 220 megabaiti serveri kõvakettaruumi. Ma juhtisin tema tähelepanu asjaolule, et kaasaegsete kõvakettahindade juures maksis see ruum vähem kui minu poolt töö juures tarvitatud tualettpaber, ning isegi 10 minuti kulutamine oma kodukataloogi tühjendamiseks oleks taevanikisendav tootlikkuse raiskamine.

Tipptasemel meeskonnad ei piina oma programmeerijaid. Kehvade töövahendite põhjustatud pisikesed ebameeldivused summeeruvad ning muudavad programmeerijad õnnetuteks virisejateks. Ja virisev programmeerija on ebaproduktiivne programmeerija.

Lisaks meenutagem, et programmeerijaid on lihtne ära osta neile uusimate ja vingeimate arvutite-lisaseadmete-programmiversioonide pakkumisega. Ausalt öeldes on see ka tublisti odavam neile tipptasemel palkade maksmisest!

10. Kas teil on olemas testijad?
Kui teie meeskonnas pole spetsialiseeritud testijaid (vähemalt üks iga kahe-kolme programmeerija kohta), siis te kas tarnite vigast koodi või raiskate kõvasti raha, pannes 100 dollarit tunnis saavat programmeerijat tegema 30-dollarilise tunnipalgaga testija tööd. Testijate arvelt koonerdamine on nii karjuvalt vale majandamine, et mulle jääb täiesti mõistetamatuks, kuidas inimesed sellest aru ei saa

11. Kas lasete töökohataotlejail intervjuu käigus koodi kirjutada?
Kas võtaksite tööle mustkunstniku, ilma et oleksite palunud tal mõnda oma trikkidest näidata? Ilmselt mitte.

Kas palkaksite koka oma pulmalauda ette valmistama, eelnevalt tema tehtud toite proovimata? Kahtlen selles. (Noh, tädi Marta võtaksite võib-olla küll, ja ta oleks teiega igavesti tülis, kui te ei laseks tal teha tema „kuulsat“ maksa-ja neerupirukat).

Kuid iga päev võetakse programmeerijaid tööle nende CV või kes-teab-kust pärineva reputatsiooni baasil või ka lihtsalt seepärast, et intervjueerija nautis töövestlust. Heal juhul küsitakse kandidaadilt mõni „mille poolest erinevad CreateDialog() ja DialogBox()“-tüüpi küsimus, mille vastus on dokumentatsioonist kergesti leitav. Te ei pea huvi tundma, kas kandidaat on suutnud meelde jätta tuhandeid programmeerimiskeelte ja –pakettide detaile. Te peate huvi tundma, kas kandidaat on võimeline tootma koodi. Kõige halvem on, kui kandidaadilt küsitakse IQ-testides ning mõistatustes levivat tüüpi küsimusi (neid, mis on imelihtsad, ui vastus on teada, kuid mille vastust on peaaegu võimatu välja mõelda).

Palun lõpetage selline tegevus. Kasutage intervjuus sellist lähenemist nagu soovite, kuid pange kandidaat koodi kirjutama. (Põhjalikumaid nõuandeid saate mu artiklist Guerrilla Guide to Interviewing.)

12. Kas kasutate * hallway usability testing?
*hallway usability test on see, kus te nabite kinni esimese trepikojas kohatud inimese ning panete te katsetama oma justvalminud koodi. Korrake seda viie inimesega ning te olete avastanud 95% kõigist oma produkti kasutusprobleemidest.

Hea kasutajainterfeisi disainimine pole nii raske kui teile ehk tundub, ning on hädavajalik panemaks kasutajad teie produkti ostma. Lugege mu kasutajainterfeisi disainile pühendatud raamatut, mis kujutab endast teemasse sissejuhatust programmeerijate tarvis.

Olulisim kasutajainterfeisi teema juures on siiski asjaolu, et kui te näitate oma programmi mõnele inimesele (tavaliselt piisab viiest-kuuest), leiate kiiresti ja kergesti üles, mis te olete valesti teinud. Lugege Jakob Nielseni artiklit saamaks teada, miks see nii on. Ka keskpäraste disainerivõimetega programmeerijana saate oma produkti kasutatavust tublisti parandada, tehes järjepidevaid * hallway usability tests, mis ei lähe ka midagi maksma.