Joel on Software

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)

 

Miért ritkítsuk meg az emberi feladatváltásokat?


Szerző: Joel Spolsky
Fordította: Verók István
Szerkesztette: Orlovacz Peter
2001. február 12.

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

A számítás B számítás
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

… 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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

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).

Módszer A számítás befejezése B számítás befejezése Átlag
Soros 10 másodperc 20 másodperc 15
Multitaszkolás 19 másodperc 20 másodperc 19.5

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:

Módszer A számítás befejezése B számítás befejezése Átlag
Soros 10 másodperc 20 + 1 feladatváltás =
20.5 másodperc
15.25
Multitaszkolás 19 + 18 feladatváltás =
28 másodperc
20 + 19 feladatváltás = 29.5 másodperc 28.75

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

Módszer A számítás befejezése B számítás befejezése Átlag
Soros 10 másodperc 20 + 1 feladatváltás =
80 másodperc
45 másodperc
Multitaszkolás 19 + 18 feladatváltás =
1099 másodperc
20 + 19 feladatváltás = 1160 másodperc majdnem 19 perc!

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?



A fordítás alapjául szolgáló angol cikk címe: Human Task Switches Considered Harmful  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky