Joel on Software   Joel, szoftverekről

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

Egy programozócsapat vezetőjének legelső dolga legyen a helyes feladatkiosztás megtanulása. A „feladatkiosztás” csak egy jól hangzó szó, jelentése mindössze: tennivalók adása embereknek. Ez a héber szlengben csak „fájlzúdítás” néven szokott szerepelni (mert az ember ilyenkor egy rahedli fájlt szokott szerencsétlen dolgozók nyakába zúdítani). Annak eldöntése viszont, hogy melyik nyakba melyik fájlok kerüljenek, nagyon fontos. Ha jól csinálod, hihetetlenül megugrik a termelékenység. Ha viszont rosszul, abból szoktak mindenféle ragacsos szituációk előállni, amikor senki nem tud semmit végigcsinálni, és mindenkitől csak a „hát itt soha semmi nem készül el” panasz jön vissza.

Mivel ez az oldal programozóknak szól, egy programozási problémafelvetéssel fogunk bemelegíteni. 

Tegyük fel, hogy két különálló számítást, A-t és B-t, kell elvégezni. Mindkettő 10 másodpercnyi processzoridőt igényel. Egyetlen CPU áll rendelkezésre, amiről most feltesszük, hogy nincs más beütemezett feladata.

Ezen a feltételezett processzoron nem kötelező multitaszkolni. A két számítás tehát végezhető egymás után…

Soros feldolgozás

… vagy multitaszkolva. Utóbbi esetén ez a bizonyos CPU 1 másodperces időszeleteket használ, és a feladatváltás nulla idő alatt lezajlik.

Multitaszkolás

Melyiket érdemesebb választanunk? A legtöbben érzés alapján a multitaszkolásra szavaznak. Mindkét esetben mindkét végeredmény megérkeztéhez 20 másodperc kell. Fontoljuk csak meg azonban, mennyit kell várni a számítások eredményeire külön-külön.

A (kékkel jelölt) B számítás eredményét mindkét esetben 20 másodperc elteltével kapjuk meg. Viszont nézzük csak meg az A számítást. Multitaszkolásnál 19 másodperc kell hozzá… soros feldolgozásnál azonban csak 10 másodperc.

Más szavakkal, e szépen kitalált példában a számítások átlagos befejezési ideje soros feldolgozásnál kisebb (15 másodperc), mint multitaszkolásnál (19,5 másodperc). (És ez igazából nem is csak egy kitalált példa -- Jared munkája során jött elő egy hasonló, ami ezt inspirálta).

Az előbb azt mondtam, hogy „a feladatváltás nulla idő alatt lezajlik”. Valódi processzorokon a feladatváltás időbe telik… voltaképp annyi időbe, ami alatt a CPU regisztereinek állapotát elmentik és a másik feladat megfelelő regiszterértékeit betöltik a helyükre. A valóságban ez majdnem teljesen elhanyagolható. De hogy ne unatkozzunk, tegyük fel, hogy minden feladatváltás fél másodpercet vesz igénybe. Ezzel még inkább romlik a helyzet:

És most … csak a vicc kedvéért, tudom, hogy elég furcsa ötlet … mi volna, ha minden feladatváltás egy teljes percig tartana?

Minél tovább tart egy feladatváltás, annál rosszabb a multitaszkoláson elpazarolt idő.

Ez azért önmagában nem egy világrengető eredmény, ugye? Lehet, hogy rövidesen mindenféle futóbolondok fognak felháborodott hangvételű emailekkel bombázni, amiben „multitaszkolás-ellenességgel” vádolnak majd. „Visszavágyna a DOS idejébe, amikor az 1-2-3-at csak a WordPerfectből kilépve lehetett futtatni?” kérdik majd szemrehányóan.

Holott közel sem erre akarok kilyukadni. Csupán a következőben szeretném, ha megegyeznénk:

a) a soros feldolgozás átlagosan gyorsabban vezet végeredményekre, valamint

b) a feladatváltás időigényének növekedtével a multitaszkoláson elvesztegetett idő is egyre nő.

Rendben, most a CPU-k helyett térjünk vissza az emberek kezelésének jóval érdekesebb világába. Itt azt érdemes tudni, hogy a programozók feladatváltásai sokkal-sokkal-sokkal hosszabb időt vesznek igénybe. Nyilván, mivel a programozás kifejezetten sok dolog fejbentartását igénylő tevékenység. Minél több dolgot tartasz fejben egyszerre, annál jobban megy a programozás. Egy teljes sebességgel kódot író programozó kismillió dolgot tart egyszerre fejben: változóneveket, adatstruktúrákat, fontosabb API-kat, saját készítésű és gyakran használt segédfüggvények neveit, még a forráskódot tartalmazó alkönyvtár nevét is. Ha most ez a programozó három hétre Krétára megy nyaralni, akkor mindezt elfelejti. Az emberi agy mintha a rövidtávú RAM-ból mindent mágnesszalagra mentene le, ahonnan az egészet persze csak egy örökkévalóság alatt lehet megint visszaidézni.

Mennyi idő is szükséges ehhez? Nos, a szoftvercégem ben nemrég abbahagytuk az addigi munkánkat (a CityDesk kódnevű szoftver fejlesztését), hogy egy végszükségben levő ügyfélnek nyújtsunk három hétig elsősegélyt. Amikor visszatértünk, mintha további három hét kellett volna a CityDesk fejlesztésére visszaállni.

A tendencia személyes szintre lebontva is látszik -- ha egy ember kap egy feladatot, akkor azzal gyorsan elkészül, de ha ugyanez az ember két feladatot kap, akkor nem nagyon történik bármelyikben is előremozdulás. Vagy az egyikre áll rá és elhanyagolja a másikat, vagy mindkettő annyira lassan fog haladni, hogy ahhoz képest az éticsigák is menetszelet kavarnak. Ez persze abból adódik, hogy a programozási feladatok közti váltás igen sok időt vesz igénybe. Személyes tapasztalatom szerint, amikor egyszerre két feladattal próbálok megbirkózni, akkor kb. 6 órányi feladatváltási idővel kell számolnom. Egy nyolcórás munkanapból ez mindössze két órára rövidíti le a tényleges munkaidőt. Elég elkeserítő.

Végeredményben tehát, ha valakinek két feladatot osztunk ki és ő az egyiket „éhezni” hagyja, akkor hálásak lehetünk neki, mert többet fog elvégezni, és átlagosan rövidebb időt fog egy feladattal eltölteni. Mi több, a valódi kőkemény tanulság az, hogy egy embernek sosem szabadna egyszerre egynél több feladaton dolgoznia. Az a jó, ha ki is jelöljük neki azt az egyet. A jó vezetők a dolgozók előtti akadályok elhárítását tartják saját feladatuknak, így az emberek egyetlen dologra koncentrálhatnak és azt hamar elvégezhetik. Amikor tehát vészhelyzet támad, tanácsos elgondolkodni: valóban muszáj egy mélyen koncentráló programozót kirángatni és ráállítani, vagy mi magunk is el tudjuk simítani?