Egynemű házasság

Nemrég egy új főnökömnek (gyűjtöm a managereket) próbáltam elmagyarázni hogy mi a szituáció a projecten és valahogy ez a megnevezés jutott eszembe: egynemű házasság.

Az egynemű házasság alatt azt értem, hogy a projectre úgy helyeznek új munkaerőt, hogy az a projecten már meglévő fejlesztők képességeit nem kiegészíti, hanem azt lefedi.

A skálázhatóság témában szokás ezt X-axis-nak nevezni, és ott jól produkál, tipikusan webalkalmazásokat egész könnyű (ha nem csinált valaki valami turpisságot) X-axis mentén skálázni. A lényeges különbség viszont az, hogy a számítógépekkel összevetve az emberek lassan tanulnak és ráadásul sok hibával, azaz mind másként tanulnak meg valamit. Ez oda vezet, hogy kialakul pár vita és persze személyfüggő, hogy mennyi, de egyre több koordináció válik szükségessé. A problémán az sem segít, hogy az emberek természetes viselkedése a versenyzés, ez ugyanis nem minden eset válik a szoftver javára például gyakoribbá vállnak a túlmérnökölt megoldások.

Hát ennyit akartam megosztani ma, hogy én így gondolkodok erről nagy általánosságban véve, a többi bullshitet költsétek ti hozzá :)

code review

A közhiedelem az, hogy a code review során a problémák nagy részét elkapjuk és kitekerjük a nyakát. Ez igaz is lehet egy bizonyos mértékig, de csak egy bizonyos mértékig. Nekem úgy tűnik, hogy a code review során gyakran új bugokat hozunk létre, az alábbi okokból:

• A reviewer személye mindig más. A mindig más személynek mindig mások a szempontjai. Például van olyan, aki azért dobja vissza a patch-et, mert nem final egy változód benne, van aki azért mert az és neki nem tetszik. "ha van kalapod, azért, ha nincs kalapod, akkor meg azért". Valljuk be, ez a final dolog még bölcsészek között is baszakodásnak számítana.
• A patch-ek szétválasztása és egyesítése tulajdonképpen kódolási tevékenység (azaz idővel és kockázatokkal jár) míg a végeredményhez semmilyen értéket nem tesz hozzá.
• Teljesen beteg vagyok attól, amikor valamit kétszer kell megcsináljak. Na és az még a jó eset :-) Ha elsőre jó volt, másodszor biztosan elcseszem.

Szóval a lefikázás után valami konstruktívat arról, hogy szerintem hogyan kellene használni a gerrit-et:

• Ha egy patch jobb állapotot hagy maga után, mint elötte, akkor had menjen. Lépjünk tovább, ne szarozzunk!
• Ha hiányzik belőle valami (de ugyanakkor attól még jó), akkor esetleg a reviewer hozzáírhat egy patchet és beküldheti, megmutathatja az eredeti patch szerzőjének, hogy ő még ilyesmire gondolt. Lehet vitatkozni, vagy örülni hogy "gyá télleg, köszi!"
• A fast forward policy csak több munkát hoz, gyakorlatban nem védett meg minket semmilyen hibától. Ezt a funkciót egyszerűen kijátszuk, mert nincs más választásunk.

Szóval én inkáb piacnak képzelnék el egy jól működő dolgot, mint vizsgabizottságnak. Lehet ezt is jól csinálni, csak mi nem úgy csináljuk. Megpróbáltam demózni az ötletet és egy pár hétig egy-egy embernek végignéztem a patch-setét egyenként ellenőriztem és ha jó volt egyből be is mergeltem. Szépen haladtunk. Mindenki örült, de aztán senki sem kezdte utánozni a módszert :-(

Amúgy a gerritet továbbra sem komállom, mert:

• A gerrit üzenetei suttyók - pl ezért én soha senkinek nem adok -1-et, mert az olyan bunkó szöveg, hogy inkáb fogalmazok valami barátibbat levélben.
• A felhasználói felülete ótvar. Ki hitte volna hogy GWT-ben is lehet ocsmány weboldalakat szerkeszteni? :-)
• A használhatósága csekély, pl keresés nagyon hiányzik belőle, de a saját lezárt patcheimet sem tudom átnézni benne.

Java Architekt - a gyakorlatban

István múlt heti postjára szeretnék egy kicsit bővebben reagálni, mint ahogy kifér egy pár soros kommentben. Technikailag nagyon korrekt definíció egyébként, de egy két dolgot hiányolok belőle és pár dologban buktatót látok.

Szóval szerintem...

Elösször is azt tenném hozzá, hogy amennyiben valaki - az architekt pl - meghatározza a szoftver archiktetkúrát, amiben a szoftver-fejlesztők dolgozni fognak, akkor annak az embernek a felelőssége az is, hogy a szoftverfejlesztők mennyire tudják hatékonyan végezni a feladatukat. Amikor egy java architekt dolgozik, akkor arra kellene koncentrálnia, hogy minnél egyszerűbb és hatékonyabb eszközöket adjon a fejlesztőknek és minden komplexitást csak valami megfelelő haszonért cserébe (customer-value) engedjen be. Én ezzel szemben nagyon sok fejlesztésben láttam valami totálisan elszállt marhaságot. A 97 things - és István is - ezt javasolja architekteknek: ne az önéletrajzodat fejleszd. Persze nem ez az egyetlen oka annak, hogy egyes java projectek krónikusan halálcsillaggá nőnek, van a dologban némi buta ego-fejlesztés is.

Többmillió java szoftverfejlesztő nevében követelem, hogy amikor kiderül, hogy egy java rendszer elcseszett ökörség lett, az architekt szüleit legalább annyira emlegessék meg, mint a szoftverfejlesztőkét!
A hegesztőmunkás is el tudja cseszni, de általában ezek az hibák általában nagyon könnyen javíthatóak. Ellenben architektúrális hibák többnyire végigkisérik a szoftver életét.

A másik észrevételem az lenne, hogy István definíciója nehezen illeszthető össze egy akármilyen agilis, iteratív szoftverfejlesztéssel. Elösször is azért, mert az architekt a definícióban elvágja a fejlesztőket a klienstől. Láttam már olyan embert, aki egész jól játszotta az információfiltert, de ez nagyon ritka, valamennyi infót mindenki elszór, a delay pedig minden embernél nagyobb, mint a másfél másodperces csúszás a telefonvonalban. Másrészt az agilis szoftverfejlesztés nem különít el hosszú tervezési szakaszt. A tervezési szakasz nálam a waterfall modell szinonímája. Aki ezzel jön elő, az általában valami olyasmit forgat a fejében. Aztán tipikusan a fejlesztés alatt kiderül hogy jajj, az úgy finoman fogalmazva is szuboptimális lesz, de akkor már bukó van, mert implementálni köll.

Aztán a harmadik észrevétel: egy-egy cég szokásait és procedúráit kitanulni időnként évekig is eltart, de legalább hónapokig. Én ha nagycég lennék, inkáb a belső emberek között keresném a leendő architektek legalább egy részét. Persze nagyon jól jöhet a más cégtől érkező tapasztalat is, de annak még jó sok idő, amíg kitapasztalja, hogy mi működik és mi nem működik valójában az új helyén.

Aztán még egy utolsó észrevétel a tanulással kapcsolatban: Nagyon jó, ha valakinek volt rá pár milkája hogy meghallgassa az Oracle/IBM/SAP/RedHat/Anyámtyúkja kurzusát, de az katasztrófa, amikor ezek után a kurzusok után, a fenti cégek technológiáit és termékeit lenyomkodja a fejlesztők, a cég, a kliens és a felhasználók torkán, ha jó, ha nem jó. Ilyet pedig már mindannyian láttunk. Én inkáb olyan emberrel dolgoznék együtt szivesen, aki nem csak az Anyámtyúkja technológiáit és termékeit ismeri, nem nyalta be a marketinget, hanem gyakorlati tapasztalatai vannak, látott elcseszett és pöpec projecteket. És ha ez megvan, akkor az architekt kurzus valószinűleg nem éri meg a pénzét.

Ö... oszt ennyi, na kitomboltam magam :-)

timetraktor

Sajnos nem láttam még értelmes timetrackert, pedig láttam néhányat. Például a D-nél egy fél évre lehalt a timetracker szervere. Amikor visszajött, megint kérték mindenkitől, hogy visszamenőleg is írja be. Fél évre visszamenőleg :-) Az egyik tesztelősrác összeütött egy zseniális tesztet, ami kitöltötte autómatikusan. Innetől a bürokraták megint boldogok voltak. Ennyi kellett csak hozzá! Az üzemeltetőknek ennél sokkal durvább volt, nekik 10-15 percenként be kellett írniuk, hogy mivel foglalkoznak. Szintén bevetették a saját megoldásukat, az egyik csákó ott egy pythonos GUI-t dobott össze (egész profin nézett ki), ami bár felpopuppol neki időnként, de volt rajta egy gomb, hogy "The same as previous". Ez bemásolta az előzőt és el is tünt az ablak azonnal.
Klassz megoldások.
Volt egy saját megoldásom is. Nem klassz, csak vicces: egyszerűen csak abbahagytam a timesheet írását - ez amúgy jellemző rám, nekem tavasszal se az adóbevallás jut eszembe. Eredmény: semmi, a következő 2-3 évben senkinek sem tünt fel. Azaz valószinűleg ez egy riport volt régről, amit már senki sem olvasott el amikor ott dolgoztam. Pedig egész sok időm került elba...ra ott. Mellesleg a projectem se volt felvéve, szóval úgyis csak kamuzni tudtam volna benne.
A jelenlegi timetrackernek még kell valami hegesztés. Azt látom hogy sikítanak érte, ha nem töltöm ki, de akármi is lehet benne. Például egy irodán kívüli munkanapot beírtam, és szóltak hogy írjam be hogy mikor jöttem és mikor mentem. De hát nem jöttem be, nem mentem el, egyáltalán nem voltam itt. Akkor mit írjak be? :-) Akármit. Az jó, mert az nagyon könnyen automatizálható.

Én ezt tartanám értelmesnek:
Az idő nem számít, gazdálkodj vele úgy, ahogy tudsz. Csinálj valami értelmeset, vidd elöbbre a projectet.

A szoftverfejlesztés nem gyártási folyamat.

Favicon

A banános favicon tisztelgés 11 évvel ezelötti főnököm elött, akinek határozott véleménye volt, hogy a programozó egyfajta majom. Így is hívott minket, hogy majomcsapat. Messze túltett az én halálcsillagomon, a "törpök életén" meg a többi közhelyeimen, ő ha beszélt, percenként kétszer biztos bevágta. Körülbelül úgy használta, mint a mélyen művelt honfitársaink a B+-t. Bár nem hiszem, hogy mind személyesen találkoztatok vele, gondolom ez az elképzelés senkinek sem új.
Vita tárgya lehet viszont az, hogy milyen ok-okozati összefüggésben áll ez a termék minőségével. Persze nem jó, ha űbermenschnek képzeljük magunkat, de még ha szükséges is némi negatív 'feedback' a munkánkról a helyreigazítás céljából, abban biztos vagyok, hogy ez már kicsit túllő a célon.

Lásd:

• Önbeteljesító jóslat
• Codemonkey
• primate programming

Köszi a blogger.com programozóinak, hogy lecserélhetővé tették a favicont :-)

Egyébként az 'I will work for food' eredetileg nem akart utalás lenni a kódmajom életformára. Valami olyasmi volt, hogy az első Sárga-70 túra útvonalára mentem ki útvonalat mérni, toltam a rohadt sárban hegynek felfele a mérőkereket (mint a jól ismert filmben), marha éhes lettem és közben találtam ki ezt a blogot.

multitenancy

Egyik este miután a több munkatársamtól is okosodtam virtualizációról és cloudról, operációs rendszerekről, kicsit már kiégett aggyal ez a történet állt össze a fejemben (bár valószinűleg nem első alkalommal)

Úgy kezdődött, hogy célgép. Mint pl az IBM csodálatos lyukkártyás rendszere még az 1940-es években amivel (a Corporation cimű film, emlékeztek... és más források szerint) oly sok embert továbbítottak a másvilágra. Ezek csak erre az 1 dologra voltak jók, nem volt cserélhető programjuk. Ahhoz képest azért igazán drágák voltak, de még így is sok pénzt takarítottak meg.
Ahogy tellett az idő, az emberek szerettek volna jobb befektetést csinálni, azzal, hogy többféle dologra használják a gépet. Így született a program. Eleinte 1 program futott egy időben egy gépen, de cserélhető volt. Ennél nem nehéz jobbat elképzelni: szeretnénk, ha egy időben egy gépen több program is futhatna.
Hát rohadtul leegyszerűsítve valami ilyen igényből született az operációs rendszer. Persze az OS pár szép dologgal jön még: filerendszer, hogy ne kelljen a disk-kezeléssel a programnak foglalkoznia, felhasználók, I/O, hálózat, felhasználók, memóriakezelés, sorolhatnám... tök jó helyen vannak ott. Kell mind.

Amikor viszont már több felhasználó több programja fut az 1 szál drága vasunkon, akkor igen valószinűvé válik, hogy össze fognak veszni az erőforrásokon. A felhasználók is, de a programok még inkáb. Gondolom nem kell példákat hozni memória-zabáló programokra, vagy CPU-zabólókra. Ez még a kissebbik baj lenne, de a konfigurációjuk is igencsak elburjánzott. Itt példaként említeném a hosts filet, amibe mindenki mindenféle ocsmányságot beletol, amit a DNS admin nem akart megcsinálni. Aztán vannak a szoftver-függőségek, kifejezetten az enterprise genyákon pl az SAP-nek meg az Oracle-nek kötelező valami olyan oprendszert venni, ami tanúsított ésatöbbi. Az adminisztrációval is kezdtek bajok lenni. Szóval oda jutottunk, hogy majdnem minden nagyobb rendszerünkhöz mégiscsak külön szervert veszünk. Bár mostanra nem egetrengetően drága egy szerver, azért mégiscsak drága _minden_ szoftverünkhüz külön szervert venni. Valahogy tényleg egyre több és több szoftvert használunk ahogy egyre több dolgot próbálunk számítógéppel csinálni.

Kis kitérő: amit a java csinál több szoftver-rendszer békés együttélése címén egy VM-en belül az a gyakorlatban ritkán vezet boldogsághoz. Igen, nem nyúlhatsz bele immutable objektumokba, nem babrálhatsz bele másik webapp kódjába, de ennyi és kész. A másik app felzabálja a memóriát vagy agyonhajtja a GC-t, felstartol 1000 idióta szálat, beblokkolja az összes http listener szálat, elfelejti zárni a streameket és kifutsz a file handle-kből, sorolhatnám. Van még itt ez az extrémebb eset is a the daily WTF-ről, nagyon gonosz. Ezer módon lehet az együttélés két java webapp között zűrös. Persze a jó programokra ez nem vonatkozik, de azokkal nincs is semmi gebasz, most a hülyékről van szó. Nem tudom a hülyék többen vannak-e, de azok több időmet viszik el.

A kis kitérő után eljutottunk a virtualizációhoz, ami lehetővé tette, hogy egy vason több oprendszer is futhasson a saját agyontákolt konfigurációival, a összebuherált szoftvereivel és nem vesznek össze, nem is tudnak egymásról.
Egyvalami nagyon nem tetszik még ebben: Rohadt nagy, drága szerverek. Ellentétes az általam tapasztalt valósággal.  Egy hazai Pince Programming Kft-nél, de akár a százmilliós kormányzati projecten is a következőképpen működik a fejlesztői infrastruktúra: a rendszergazditól elkunyizzátok azt a Juliska néni leselejtezett gépét, amit már odacsűrt a kukára de még nem vitték el. Kicsit köhög a vincsi de még megy. Toltok rá Kedvenc Linuxot, Jenkinst, subversiont, gitet, sonart vagy amit akartok, berúgjátok az asztal alá és hajtjátok. Néha a takinéni kirángatja belőle a drótot (miközben letörli a képernyődet vizes ronggyal, pl amivel felmosott), ilyenkor kicsit kurblizni kell. Néha a rendszergazdi ellopja és kidobja megint, a kukásoktól visszaszerzitek. Ez így nektek ismerősen hangzik?

A másik probléma a nagy szerverekkel: egyszer minden gép befosik. Én olyat még nem láttam, ami nem. Jöhettek a legendákkal a befalazott gépekről, amit a nagybátyád unokatestvérének régi munkatársa másodkézből hallott. Amikor a crash megtörténik, nem 1 rendszered fekszik hanyatt, hanem mind. Kellemetlen.

Szóval magánvélemény erről a sima virtualizációról:

• Szerintem tipushiba 1 böszme nagy gépet venni és arra tenni az összes VM-et. Ez mainframe-szerű maszturbáció. Ott fog állni az összes engineer és fogdossák a nagy gépet hogy jajjdejó. Persze jó én is birom ezeket a nagy böszme dobozokat, de több kicsi géppel jobban jársz teljesítmény és biztonság szempontjából is.
• Az nagyon fontos, hogy a virtuális gépek ne legyenek szerverhez kötve, mert amikor égnek, együtt megy füstbe a valódi vassal a virtuális géped.

Szóval végülis odajutottunk a cloud-hoz. A virtualizáció csak egy lépés volt és a következő lépés a cloud. Vannak publikus cloud-ok, amik egész olcsón rohadtul nagy számítási kapacitást árulnak. Vannak private cloud-ok, amik a saját vasadon lehetővé teszik, hogy a virtuális gépeidet futtasd.

Ami nekem az egészben furcsa, hogy pl egy virtuális gépen egy java VM-et futtatunk. A host OS is és a Guest OS is virtuális memóriát kezel. Hány layer virtualizáción mentünk keresztül? Meg mennyire is lett ez az egész komplex?

Átlag

Egy csomó olyan programozóval volt dolgom, akik úgy építettek szoftvert, hogy egy rakás komplexítást toltak bele, amire mindenhol figyelni kellett. Persze ezerszer belebotlottak saját maguk is. A varázsige az volt, hogy a szoftverfejlesztő nagyon inteligens és egyáltalán nem felejtékeny. Legalábbis mindkét képessége az átlag-ember felett van. A botlások alkalmával pillanatra feélretették ezt a feltételezést, és aztán csavartak mégegyet az architektúrán, megint végígtúrták az egész kódot és közben megerősitették hitüket, hogy cefet jó programozók.

Ez a megfigyelés (ami igyekezett objektív lenni, de csak eddig a pontig), és most a magánvélemény. Én ezt kapcsolatba hozom ezeknek a szoftver-projectkenek a problémáival. Azt feltételezték magukról a programozók, hogy nagyon nagyon okosak. És hát kétségtelenül azok is, csak nem annyira, amennyire hiszik. Egészen biztosan feledékenyebb vagyok az átlagnál és talán butább is. Lustaság szempontjából nem tudom hogy állok, annyi biztos, hogy a repetatív munkát nagyon hamar megunom és akár pár perc múlva már sorozatban szúrom el, annak ellenére hogy hamar ráállt a kezem és az elején egész jól ment. Előfordulhat, hogy lusta is vagyok. Szóval én inkáb arra szavaznék, ne építs semmit arra a feltételezésre, hogy zseni vagy és a munkatársaid is mind legalább géniuszok.
És ez a lényeg: a sok magamfajta hülye karbantarthatóbb, átláthatóbb és megbízhatóbb rendszert fog csinálni, mint azok, akik zseniknek hiszik magukat, de nem annyira azok, mint amenyire hiszik. Természetesen ez az igazi zsenikre nem vonatkozik, de idáig a guru egy mitosznak tűnik, soha nem találkoztam guruval. Pedig már tolom egy ideje a szekeret.

Hozzáállás: Én vagyok Gipsz Jakab. Minden fán ilyen terem.

Kicsit emészthetőbb formában egy hasonló vélemény itt: http://97things.oreilly.com/wiki/index.php/Don%27t_Be_Clever
A 97 things nagyon kedves kis gyüjtemény, érdemes olvasgatni. Van pár extra is hozzá, ami a könyvben nincs benne. (Megvan otthon a nyomtatott könyv, példaként arra, hogy CC tartalmat is el lehet adni)

Még egy hasonló lelkületű alapozó itt :-)