Bár az alábbi cikk nem tartozik szorosan az adatvédelem és az IT biztonság témaköréhez, azonban ha tovább gondoljuk a cikkben leírt gondolatmenetet könnyen beláthatjuk, hogy egy leterhelt programozónál nagyobb az esélye annak, hogy pl. biztonsági szempontból nem olyan minőségű kódot fog előállítani, mint azt tette volna nyugodtabb feltételek esetén. Ily módon akár sérülékenységet tartalmazó szoftver is készülhet, amelyet kihasználva adatszivárgásra nyílik lehetőség. Nyilván ez egy extrém eset, tekintve, hogy a kódokat jó esetben több körben ellenőrzik kiadás előtt (de a probléma valóban létezik, gondoljunk csak pl. a hibásan kiadott Microsoft frissítésekre). - ITsec

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

Forrás: http://hungarian.joelonsoftware.com/Articles/TaskSwitches.html

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:

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 szerző:

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.