deviantart.com

Nap mint nap szembesülök azzal a problémával, hogy ha valakitől elveszik a felelősséget, a motivációja és a munkájának minősége a töredékére csökken. Ugyanezt tapasztalom a gyereknevelésben is, ha nagyon figyelsz egy kölyökre sokkal nagyobb eséllyel szenved balesetet, mintha rábíznád az önfenntartás felelősségét és a tettei következményének viselését.

Andy Hunt és Dave Thomas a Pragmatikus Programozók, akik a minőségi szoftver létrehozásának elismert nemzetközi szakértői. A szoftverfejlesztés során követendő gyakorlatról szóló sikerkönyvük, A Pragmatikus Programozó: szakmunkásból mester, a fejlesztés közben felmerülő kérdések széles körét érintő jótanácsokkal van tele.

Az alábbi interview forrása: http://www.artima.com/intv/fixitP.html

Magyar fordítására pedig a HUP -on találtam rá: http://hup.hu/node/66456

A mesterségbeli tudás és a katedrális

Bill Venners: A PP könyv előszavában, Quarry munka-hitvallását idézitek:
Nekünk, akik a csupasz köveket faragjuk mindig látnunk kell magunk előtt a katedrálist is.

Majd, azt mondjátok: „A projekt struktúráján belül mindig van tere az egyéniségnek és a mesterségbeli tudásnak.”

DT: Egy nagyon struktúrált környezetben az emberek hajlamosak feladni a felelősséget. Azt mondják: „Ez többé nem az én dolgom. A főnököm megmondja mit tegyek. Megkaptam a tervet. Csak ezt és ezt a részt kell megcsinálnom.” Ez az analógia a kőművessel, aki a hatalmas egésznek egy nagyon kis része. A valóságban a katedrálist építő kőművesek komoly, nagytudású mesteremberek voltak. Mindig tudatában voltak annak a ténynek, hogy a munka, amit végeznek a katedrális külső képét határozza meg. Amit itt mondunk, az az, hogy még ha úgy érezzük is, hogy nincs felhatalmazásunk vagy felelősségünk jól csinálni, a valóságban mégis van. A munkánk minősége fontos. Hozzájárul a projekt átfogó hatásához vagy eredményéhez.

AH: Másrészt ez lehetővé teszi és bátorítja az egyéni ötleteket. De nem vihetjük túlzásba. Katedrálist építünk. Úgy kell kialakítani a vízköpőt, hogy a hely átfogó témájába és koherens hangulatába illeszkedjen. De az egész átfogó tervezési kötöttségein belül megmarad az egyéni ötletesség szabadsága, mellyel a legjobban járulhatunk hozzá az egészhez.

BV: Miért fontos ez?

DT: Két okból. Először is, a programozás nagyon nehéz. Elképesztően nagy elkötelezettséget igényel jól csinálni. Azért, hogy motiváld magad, hogy elkötelezett maradj, büszkének kell lenned arra, amit csinálsz. Ha ehelyett egy mechanikai szerelőszalag melletti munkásnak tekinted magad, akinek egyedüli munkája a specifikáció alapján bájtok produkálása, akkor nem lesz elég érdeklődés benned, ahhoz hogy jól végezd, amit csinálsz. Tehát a globális perspektívából nézve ez nagyon fontos. Személyes szemszögből tekintve, miért kéne olyan munkát végezned, amit nem élvezel? Fontos, hogy élvezd, ha már ennyire elkötelezed magadat egy munkával.

AH: Az egyéni művészi szabadság fontos, mert minőséget eredményez. Példaként vegyük, hogy egy vízköpőt készítesz ennek az épületnek a sarkára. Az eredeti specifikáció vagy nem mond semmit vagy csak azt, hogy olyannak kell lennie, mint ezeknek a szimpláknak. Közben rájösz: „Nézd csak! Ha a vízköpő száját így alakítom, akkor a víz itt jön le és úgy távozik. Ez jobb lenne.” Jobban tudsz reagálni a helyi feltételekre, mint a tervező, aki nem tudott ezekről, nem látta előre őket, vagy nem volt tudomása róluk. Ha a te dolgod az a vízköpő, tehetsz érte valamit és egy jobb végterméket állítasz elő.

A Törött Ablak Elmélet

BV: Mi a törött ablak elmélet?

AH: A városok leromlását tanulmányozó kutatók meg akarták érteni, hogy miért kerüli el a belváros bizonyos részeit szlömösödés, és hogy a közvetlen szomszédság – ugyanolyan demográfiai és ökonómiai adottságokkal – miért válik pokollá, ahová a rendőrök is félnek bemenni. Tudni akarták mi a különbség.

A kutatók csináltak egy tesztet. Vettek egy szép autót, mint pl. egy Jaguár és leparkoltatták New York Dél-Bronx-i részén. Egy rejtekhelyre vonultak vissza és onnan figyelték mi történik. Ott hagyták az autót vagy négy napig és semmi sem történt. Hozzá sem nyúltak. Ekkor odamentek, betörték egy kis oldalsó ablakát és újra elrejtőztek. Nem telt bele négy óra és az autót felfordították, felgyújtották, lecsupaszították – teljesen.

Tovább tanulmányozták a témát és kidolgozták a Törött Ablak Elméletet. Egy ablak betörik egy bérházban, de senki nem javítja meg. Úgy hagyják. Aztán valami más is eltörik. Lehet véletlen baleset, vagy nem, de szintén nem javítják meg. Falfirka jelenik meg. Egyre több sérülés halmozódik fel. Nagyon gyorsan exponenciálissá válik ez a folyamat. A teljes épület leromlik. A bérlők elköltöznek, a bűnözés beköltözik. A játszma elveszett. Mindennek vége.

A törött ablak elméletet metaforaként használjuk a projekten belüli technikai adósságok kezelésében.

BV: Mi az a technikai adósság?

AH: Ez egy kifejezés a Ward Wiki-ből. Minden alkalommal, mikor elhalasztasz egy javítást, egy adósságot hozol létre. Tudhatod, hogy valami rossz, de éppen akkor nincs időd megjavítani. Bumm! Megy a főkönyvbe. Adós lettél. Van valami, amit meg kell javítanod. A valódi adóssághoz hasonlóan, ez rendben van, ha kezeled. Ha van néhány ilyened – akár jónéhány is – ha ura vagy a helyzetnek, rendben van. Elkészülsz egy új verzióval időben. Aztán visszatérsz és megfoltozol néhány dolgot. De a valódi adóssághoz hasonlóan, könnyű oda eljutni, mikor nem fizeted vissza, mikor olyan sok problémád lesz, hogy sohasem térsz vissza és oldod meg őket.

DT: Az aktuális hasonlatom erre a bejövő leveleimé. Ugyanis időnként megvan az a szokásom, hogy nem válaszolom meg a leveleket egy ideig. És aztán eljutok odáig, mikor kb. 250 ilyen lesz, mikor hirtelen rájövök, sosem fogom őket megválaszolni.

BV: Hogyan hozható kapcsolatba a technikai adósság a törött ablakok elméletével?

AH: Nem akarod hagyni, hogy a technikai adósság kicsússzon a kezedből. Meg akarod állítani a kis problémákat mielőtt nagyokká válnak. Guiliani főpolgármester használta ezt a megközelítést nagyon sikeresen New York városban. Nagyon szigorúan ügyelt olyan kisebb együttélési szabályok megszegésére, mint pl. az úttesten nem megengedett helyen történő átkelés, falfirka, kéregetés – szabályszegések, melyek úgy gondolhatjuk nem számítanak, – és így sikerült nagymértékben lecsökkentenie az olyan komoly bűnesetek mértékét, mint gyilkosság, csempészet, rablás kb. 4,5 -5 év alatt.

A pszichológia területén ez lényegében működik. Ha teszel azért, hogy a kis problémákat kézben tartsd, nem növekednek és válnak naggyá. Nem okoznak további kárt. A rossz kód a saját funkciójához nem kapcsoltan jelentős mértékben járulhat további problémákhoz. A rendszer más részeiben is elkezd gondot okozni, ha nem uralod. Tehát nem akarsz törött ablakokat a projektedben.

Mihelyt valami rossz lesz – legyen az hiba a kódban, probléma a folyamatban, rossz igény, rossz dokumentáció – valami, amiről tudod, hogy nincs rendben, tényleg meg kell állnod, ott és akkor meg kell oldanod. Javítsd csak ki. És ha nem tudod éppen megtenni, keríts köré kordont. Jól jelöld meg! Legyél biztos benne, hogy mindenki tudja, nincs rendben és hogy nem szabad megbízniuk benne, a közelébe se menjenek! Ahogy valami problémás lesz és nincs kijavítva, elkezd rossz közérzetet terjeszteni a csapaton belül. „Nos, ez nem OK. Ó, hát éppen elrontottam.”

Törődj vele, hogy mások is így tegyenek

DT: A lényeg az, hogy mutasd, odafigyelsz. Vegyünk például olyan kódot, amit a csapat használ, de elsődlegesen az enyém. Vannak benne részek, melyek nyilvánvalóan rosszak, de nem úgy látszik, hogy foglalkoznék velük. Úgy hagyom őket. Bárki, aki e modult látja azt mondhatja: „Nos, Dave nem törődik evvel. Ez az övé. Miért kéne, hogy engem zavarjon?” Tulajdonképpen, ha a modulomban írsz valami mást, ami rossz, azt mondhatod: „Dave nem törődik vele, nekem miért is kéne?” Ez a fajta lepusztulás megtörténik a kódrészletekkel és a bérházakkal egyaránt.

Másrészt, tegyük fel, hogy észreveszek egy határesetet a kódomban, ami nem működik. Tudom, hogy hiba, de nem kritikus az alkalmazás mindennapjaiban és most nincs időm kijavítani. Legalább egy megjegyzést odarakhatok. Vagy, ami még jobb, egy assertion-t, így ha bármikor erre az ágra téved a végrehajtás, valami történni fog, ami mutatja, hogy kézben tartom a helyzetet. Evvel mindenekelőtt könnyebbé tettem a probléma azonosítását. De azt is mutatom másoknak, hogy mennyire törődök vele, így ők is javíthatják a hibákat, ha találkoznak velük.

AH: Ha bekerülsz egy projektbe, ami csak döcög, – mindenhol hibák, a fordítás nem egészen működik – nem fogsz nagy késztetést érezni, hogy a legjobbat nyújtsd. De, ha egy olyan projekt része leszel, ahol minden takaros, akarsz az első olyan lenni, aki hibás kódot ír?

BV: A könyvetekben leírtok egy történetet egy tapéta tűzről.

AH: Egy korábbi könyvelőm Connecticut-ban egy nagyon előkelő, gazdag városrészben lakott, egy szuper lakosztályban. Volt egy tapéta darab az egyik falán, mely kicsit túl közel volt a tűzhöz és egy nap lángra kapott. A tűzoltók kijöttek. A tűz lobogott. A ház kigyulladáshoz közeli helyzetben volt. De a tűzoltók nem törtek ajtóstul a házba. Kinyitották a bejárati ajtót és leterítettek egy kis szőnyeget. És az koszos-mocskos csövet azon csúsztatva eloltották a tüzet. Aztán összetekerték a szőnyeget és elköszöntek.

Még a támadó lángok mellett is, a tűzoltók figyeltek arra, hogy szőnyeget terítsenek le és azon húzzák csöveiket! Különleges figyelemmel voltak arra, hogy ne koszolják össze a srác drága lakását. Krízis helyzet volt, de nem pánikoltak. A tisztaság és rendezettség bizonyos szintjét megtartva oldották meg a problémát. Ezt a fajta hozzáállást akarja elérni az ember egy projekten, mert válsághelyzetek mindig adódnak. A dolgok lángba borulnak és megsemmisülnek. Nem akarsz őrülten fel-alá futkosni és még több bajt okozni, amit aztán szintén ki kell majd javítani. Terítsd le a szőnyeget! Csináld jól!