"Two years ago today, I started Microsoft Windows Azure as an intern, in the very same team I joined right after college and I am working for last 8 months."
Es igen, ahogy irja ez mashol igy van sajnos. Elkezdtem olvasni es megallapitottam, ezt akar tolunk is irhatta volna valaki.
A sok meeting a sok doksi - de persze amire szukseged lenne az pont nincs - a "It is not what you do, it is what you sell." meg a "I spend most of my time trying to figure out how others’ uncommented/undocumented code work, debugging strange things and attending daily meetings. " egy ido utan demotivaloak.
Jah a copy-pasten jot rohogtem. Hanyszor lattam, hogy egy-egy hasonlo funkciot cpoy-pasteeltek, persze a hibakkal egyutt.
A masodik pontrol pedig az jutott eszembe, amikor a managereink - hogy sporoljanak az idovel - azt kertek a csapatunktol, hogy a betervezett test caseek szamat csokkentsuk 30%-al, ugy hogy technikai indokuk erre nem volt, csak a "sporolas".
Hja, pont a blogban leírtak miatt egyre inkább az a véleményem, hogy a nagy (neadjisten multinacionális) cégek hatékonysága kizárólag a méretből fakadó lobbi és adóoptimalizálási lehetőségekből adódik.
Az előző munkahelyemen abban a luxusban volt részem, hogy nem volt "menedzserem", hagytak minket dolgozni, úgy, ahogy mi azt jónak láttuk (a specifikáció kidolgozásától kezdve a késztermékig mindent). És ez komoly motiváció, bizony sikerült is jó szoftvereket csinálni. Azonban azt látom, hogy sajnos ritkaság az ilyen.
Kis, 5-10 fős teamnél tényleg felesleges tud lenni a sok menedzselés, de ahol több százan dolgoznak a kódon, ott nem lehet "átugrom a Józsihoz és megbeszéljük mi legyen"-t játszani.
Itt arról van szó, hogy pont a sok (értelmetlen) menedzselés öli meg a fejlesztést. Magának a menedzselésnek van értelme, ha jól csinálják. Én pl kifejezetten örülnék neki, ha nem engem pingelne mindenki, hanem lenne valaki, aki fogadja a beérkező kéréseket, rendszerezi és nem szakít félbe állandóan. De ez csak egy utópiának tűnik sajnos.
A daily meetingeknek van értelme, ha jól csinálják: max 15 perc, hogy a csapaton belül mindenki tudja, hogy ki mit csinál, és hol tart.
Gondolom ti nem jól csináljátok, ha azt mondod, hogy borzalmas.
Óóóó 15 perc is tud olyan lenni, mintha zombik ennék ki falatonként kis műanyag kávéskanállal az agyadat, közben meg a háttérben a buckalakók kórusa szólna.
A saját munkádból indulsz ki, ez gond. Próbáld általánosítani, mert a jelenség is az sajnos. Nem a hogyancsinálddal van a baj (azzal is lehet egy alkalmatlan vezető esetén), hanem azzal, hogy mikorcsináld vagy mikornecsináld.
Pl. Ha a fejlesztőknek ki van adva egy határidős meló és egészen konkrétan meg van határozva egy hétre előre, kinek mit kell csinálni (vagy esetleg ki vannak alakítva a 2-3 fős fejlesztői csoportok, akik folyamatosan egyeztetnek egymással) akkor hullára felesleges felállítani őket a kódtól és az üveges tekintetű embereket átrángatni egy másik világba, aztán meg visszatuszkolni őket.
A meeting oké, de a daily nem oké.
Még a daily is oké, ha oka van. Ok pl. az lehet, hogy a góré ismeri az embereit, és tudja, hogy ki az, akit egy hétre egyedül lehet (kell) hagyni, és a hét elteltével nem hümmögés meg kifogás lesz a státusz, és ki az, aki tök jól megcsinálja a dolgát, de csak akkor, ha arról naponta be kell számolnia.
Aki az egész társaságot az utóbbi módon kezeli, az nem tud saját csapatában disztingválni, vagyis legalább részben tévedésből kapja a fizetését.
Ez azért picit magyar virtus is: mi szeretjük felosztani a munkát egymást max tévedésből fedő/összefüggő részekre, és nem igazán vagyunk kiváncsiak arra, hogy a másik mit csinál.
Vezetőként ezt sokféleképp meg lehet oldani, de az egy értelmes és jogos vezetőségi igény, hogy legyen egy ritmusos (minden nap ugyanakkori) minta arról, hogy hol is tartunk, mert abból lehet látni a hümmögős részeket, amikor Józsi vagy külső vagy belső okok miatt meg van akadva.
Volt olyan team, ahol magunktól csináltuk a napi meetinget, és volt olyan team, ahol én is rühelltem róla beszélni. Minek? Senkit nem érdekel, senki nem szeretne beleszólni és senki nem fog hozzátenni.
Szóval önmagában a standup még nem működik. Ahhoz kell az is, hogy érdekelje / érdekelt legyen a másik abban, hogy mindenki másét végighallgassa, hasson az életére.
Ez borzalmas, átéltem ilyet, menekültem is a cégtől. Egy produktív, kreatív embernek agyhalál a sok értelmetlen megbeszélés (amiknek a fele csak szimpla fontoskodás). A kommentálatlan, doksi nélküli kód szintúgy. Pláne, ha évek óta megbúvó redvás hibákat kell benne javítani. Olyan kódban, amit vki egyszer elkezdett C-ben írni, aztán mindenki, aki az utóbbi 10 évben hozzáírt, a saját coding style-t használta, C++-ban is beleirogattak, stb. ahogy épp tetszett. Egymás mellett élő párhuzamos megoldások ugyanarra a problémára (mert pl. az egyik fejlesztő nem vette észre, vagy nem érdekelte, hogy már létezik egy megoldás, ő megírta a sajátját). Multiknál még külön szép, amikor a külföldi kollegák szó, kérdés, értesítés vagy code review felkérésé nélkül piszkálnak bele a mi kódjainkba is, mi meg ha fordítva így teszünk, letolnak...
Dolgozam eddig két multinál, és azt láttam, hogy a kívülről csillogó sw-ek belülről rendszerint rohadnak, de ahogy a cikk is írta, nem abból lesz a pénz, ha szép a coding style meg refaktorálják a kódot, hanem abból, ha van (új) feature a sw-ben és azt el lehet adni. A sw fejlesztő feladata meg az, hogy oldja meg, ahogy tudja (meg ahogy hagyják neki). Marketingest, ügyfelet, tulajdonost csak a bevétel érdekli és vhol ez is megérthető.
Van, akinek bejön ez a világ, van akinek nem. Láttam sok olyat, akinek elég volt napi effektív két óra munka, a maradék hatban (amiből egy óra ebédszünetet tartott) meg remekül elvolt a megbeszélésnek nevezett szájtépéseken, kávézgatásokon, Xboxozáson és egyéb multis modoroskodásokon.
Hülyének is néztek, amikor eljöttem egy kis magyar céghez, hogy alkothassak. Előtte is magyar cégnél voltam, most is, és a szakmai fejlődésem ezekben az időszakokban volt csak jó. A multiknál megtanultam néhány dolgot, hasznos volt, de ha lehet, elkerülöm őket.
+sok
ezert nem lettem en foallasu fejleszto... ha van valami erdekes projekt azt elvallalom de hogy ilyen vizfeju cegeknel dokumentaljam a ganyolast azt mar nem
Nyolc(!) honapot voltam kepes "klasszikus" multinal dolgozni.
Nyolcat. Ennyi turelmem volt a hitegetessel, hogy "most mar lassan lesznek nagyobb hozzaadott erteket kepezo munkak."
Aztan jott a telco, es megmutatta egy ember, hogy hogyan tolunk be egy Netscalerbe webes feluleten(!) egy SSL tanusitvanyt.
En meg leleptem a francba.
Szintén zenész. 10 hónap után majdnem kaptam fejlesztést, aztán az utolsó pillanatban mégis vissza akartak rakni supportra. De nem raktak mert felmondtam :P
nem iparági specialitás, ahogy az sem, hogy a legtöbb ember munkája tényleges értéket nem állít elő, majdnem minden 2 főnél összetettebb csapatnál vannak gyertyatartók, vagy pótemberek, hihetetlen potenciál van elpazarolva így
Amellett, hogy a nagy cégeket nem szeretném védeni, a nagy cégek alkalmazottainál két sérelmet ott látok lenni a metszetben:
- sokat kéne dokumentálni az anyagot,
- nincs eléggé dokumentálva az anyag.
És tényleg, ezzel a két véglettel lehet találkozni, egyik nagy cég ezerfajta doksit csináltat mindenhez (a programozók többet foglalkoznak diagramokkal mint kódolással kb.), másik nagy céget meg abszolút nem is érdekli, hogy mi az a dokumentáció kb., az arany középutat ritkán látni.
Ott van sok helyen az arany középút is: megy a mismásolás, ha le kellene doksizni valamit, de ugyanazok az emberek pampognak, ha valaki más kódjához nincs leírás. :)
Ez egy negyedik eset, "az aranyközépúttal párhuzamos rossz út", ahol csak a doksik mennyiségének az összege optimális, de ez az összeg rossz összetevőkből épül fel.
Én már nálunk is felvetettem, hogy nem lehetne azt, hogy fejlesztés közben szépen kommentezem a kódomat, pl odaírom, hogy mit csinál, majd a végén 2 kattintással generálok belőle fejlesztői doksit? De nem. Pedig hasznos lenne, feltéve, hogy egy if elé nem azt írom oda, hogy "ha a feltétel teljesül, lefuttatjuk a kódot" :)
Ahogy én most látom, igazából nem kód szintű doksira van szükség, hanem koncepcionális doksira, hogy működik az egész
rendszer, milyen részei vannak, ha új modult kell csinálni, akkor azt hova kell rakni, hogy működjön, illetve ha nem triviális
trükközések vannak, akkor azok miért történtek, mi volt az oka, és hogyan működnek. Néha még hasznos, ha le van írva, hogy
egy metódus mit csinál, de ennél bővebb doksira (a nemtriviális eseteket kivéve) szerintem nincs nagyon szükség.
"Ahogy én most látom, igazából nem kód szintű doksira van szükség, hanem koncepcionális doksira, hogy működik az egész
rendszer, milyen részei vannak, ha új modult kell csinálni, akkor azt hova kell rakni, hogy működjön"
Hatalmas +1. Mindenféle kódból generált ADI doc, mint "dokumentáció" csak illúzió.
Na meg az se hátrány, ha van funkcionális specifikáció. Merthát az sem mindig szokott lenni. :)
éppeszű fejlesztés előfeltétele kéne legyen egy normális, "VÉGLEGES" terv, ehelyett legtöbb helyen foltozás megy, kis vagy nagy cég, az biztos, hogy 99%-ban nincs határozott irány
Hiába szeretnél te "végleges" specifikációt, a delikvens nem igazán tudja, mit kér.
Ráadásul az ismereteink nem úgy vannak, hogy először ismerjük a rendszer A, B és C modulját aztán így megyünk tovább, az úgy megy, hogy felbontást látunk, és a homályos képből próbálunk kislilabizálni kontúrokat.
Lehet, hogy lónak tűnt de közelről vaddisznó.
A megoldás erre szerintem amúgy a felületprototípus. Tegyél le elé egy cuccot, ami totál úgy viselkedik és úgy néz ki mint a végleges, csak baromira nincs mögötte backend, és kizárólag memóriába dolgozik. Ez lehet hotspotokkal körbespékelt powerpointtól kezdve flashen át HTML5-ig bármi.
Emellé kb. olyan folyamatábrákat kell csinálni, amik gombokat kötnek össze képernyőképekkel.
Ha ezen kiszórakozta magát, mert ezt érti, és ezen egyszerűen tud vitatkozni, akkor már nem fog mindenféle marhasággal traktálni. Akkor már csak az ötletembereket kell leszerelni, amire a jó fejlesztői válasz "it'd take too much time. Perhaps in the next version".
Azt sose feledd, hogy mindenki másnak a UI A rendszer. Édesmindegy, milyen csodálatos backend kódot írsz, a User Interface az egy interfész, elrejti a mögötte lévő implementációt, az user szemmel nem érdekes.
Szóval a lehető legolcsóbb módon csináld meg a UI-nak egy kezelhető változatát, vedd rá őket hogy nyomkodják végig (pl. a testplaneket hajtsák rajta végig a managerek), hagyd, hogy kivitatkozzák magukat rajt, és majd néhány hét múlva amikor már nem hallani napi 3 change requestet a prototípuson, kezdd el a tényleges implementálást.
(alapvetően nem a közvetlen ügyfél számára való fejlesztésre értettem a tervtelenséget, hanem a "tömegtermelt" project-eknél is látok hiányosságokat ilyen téren, pedig ott elvileg nem 2 perce ismerték fel az igényt, és nem 5 perce kezdték el kitalálni a megoldást)
megerősítettél abban, hogy jó irányba haladunk, csak ez egyúttal azt is jelenti, hogy a fejlesztési folyamat hosszabb lesz, és az árakat részben meg kell emelnünk (amit amúgyis megtennék, mert nem az árversenyben akarok részt venni)
a másik, hogy van olyan ügyfél, akinél még ez se elég, az, hogy a fejlesztés alatt álló felülethez folyamatos hozzáférése volt, és 2-3 naponta tesztelte, még ez sem volt elég, a végén minden további nélkül kért globális változtatást, na ott hangzott el a "jelenlegi változatra szerződtünk, következő változatban benne lehet."
Amit a hozzászólásból kivettem, mert így is túl hosszú volt: az ügyfél nem a júzer. Az ügyfél (manager) soha nem fog leülni élesben kattintgatni a szoftvert, ill. a legritkább esetben.
Édesmindegy, hogy ez a megrendelő belső, vagy külső: amikor az "ügyféllel" beszélsz, azon rendszerint karóra, ing, és farmer vagy vászonnadrág lesz.
Cserébe, mint a gyerek, hisz a történetekben, és ha azt tudod neki mondani, hogy odavittük a Béluskához, akinek ezt majd használnia is kéne, és az azt mondta, hogy neki ez így jó, meg a Marika is azt mondta, aki szintén használni fogja, akkor le tud nyugodni.
Minden projektemhez iszonyat erőkkel szoktam usereket vagy user-pótlékokat keresni: user-pótlék az, aki vagy a szoftver konkurenciáját használja, vagy valami más okból az utóbbi 1-2 évben volt olyan élethelyzetben sokat, ahol a szoftver jól jött volna neki. Odaadom neki, és megfogalmazok egy célt (pl. térképes appnál találd meg a hotelt ahol tavaly nyaraltál, mittom), aztán nézem ahogy végigbukdácsol (és nem segítek neki a szoftver használatában).
Tömegszoftvernél ez amúgy könnyebb, gondold meg amikor vegyészeti szoftverhez kerestem ilyet...
Aztán már csak a managerek meggyőzése van hátra, hogy ezek hadd lássák a prototípust, lehetőleg előbb, mint ők és ne csak a végleges szoftvert mutogassuk meg.
Mutatok egy példát: egy kisprojekten egy nyomda volt az ügyfél, és diplomarendelő app kellett neki. Hülye volt és kapálódzott, hogy olyan kell, amit ő kitalált magának. Erre készült ez a doksi.. Ezek FB, GTalk, Skype chatek felékezetesítve kb, és a "na jó, elegem van" pillanattól kezdve 1-2 órába került összerakni (fb ismerősökön végignéz, ki diplomázott legutóbb, kapcsolatot felvesz, kérdéseket megfogalmaz, beír, összegyűjt, alap sablonba berak, csók). Kész szoftverre pedig a tapasztalat szerint a videó a jó.
Működik.
Persze hülyék mindig voltak és lesznek, de azért teljesen tehetetlenül nézni se szabad szerintem.
'Hiába szeretnél te "végleges" specifikációt, a delikvens nem igazán tudja, mit kér.'
Persze, hogy nem tudja, hogy mit kér, hiszen nem ritkán a saját tisztázatlan folyamataikra szeretnének informatikai megoldást, mondván, hogy a számítógép mindent megold -- aztán jön a döbb, amikor a rendelkezésre álló specifikáció alapján elkészült valami nem támogatja a káoszt.
mondom a probléma gyökerét: a gép nem intelligens, ők meg azt hiszik.
bővebben: az van, hogy aki papíron, gép nélkül nem tudja szervezni a cégét, megoldani a problémáit, az géppel se fogja. hiába az ajánló algoritmus, meg a CRM és a notification, ezt akkor csinálja a gép, ha van mögötte logika. az üzleti logika, aminek a program csak egy (ahol lehet) automatizált változata. ha nincs logika, nincs mire programot írni
hogy miért van a tévhit: mert elvetemült marketingesek eladják a saját (vagy akár más) logikájuk alapján összerakott programot úgy, hogy "új vevőket hoz", közben nem.
hogy miért van még: mert a legtöbb kivitelező fél azt mondani az ügyfélnek, hogy nem elég a terv amit elmondott, érzi az ügyfél feszültségét, bizonytalanságát, és erre jelenleg nem szoktunk rákérdezni
jó látni, hogy ezt a problémát a cégméret eszetlen növelése se oldja meg :)
"A megoldás erre szerintem amúgy a felületprototípus. Tegyél le elé egy cuccot, ami totál úgy viselkedik és úgy néz ki mint a végleges, csak baromira nincs mögötte backend, és kizárólag memóriába dolgozik."
Ja, ez elvben nagyon jó irány. Csak mivel neki a felület az UI, ezért ha lát egy teljesen jó UI-t, akkor azt hiszi, hogy a program már készen van. És mondhatod neki a jéghegyet, hogy a 90%-a a felszín alatt van, ő onnan kezdve azt hiszi, hogy a program készen van, és te csak az idejét és pénzét lopod.
"principles", na nekem is ez hiányzik midnen programnál, hogy oké, hogy egy modult kódsoronként értelmezni tudok, de ha nem tudom hogy hol töltődik be, el kell indulni a program indulásától, és kb. x000 sort át kell nézni, mire kiderül, hogy hja, tehát ez a globális változó erre van. ahelyett, hogy írnának egy leírást arra, hogy na, ezt kapja meg minden modul
pl. ez a leírás a legtöbb opensource cuccnál amivel dolgom volt annyira hiányzik, hogy a végén már mindenki beledobja a saját kódját inkább, és el is veszik az alapötlet, néha újraírásoknál megint előjön, de gyorsan nyoma vész
(ha most valaki azt mondja, hogy design patterns az elviekben jó irányba gondolkodik, csak nem futott bele a gyakorlati alkalmazásuknál lehetséges többszáz "alváltozatba")
Akkor azt az embert, aki így esik neki egy projektnek - és van dok. hozzá - nagyon gyorsan ki kell baszni a csapatból jó messzire, mert ő lesz az, akinek a kódját 3x annyi idő lesz karban tartani.
A dokumentációkban az a baj, hogy nagyon kevés helyen csinálják jól. Vagy nincs, vagy van, de túladminisztrált a rendszer, a doksik változnak, a koncepciók nem az ésszerűséget követik etc.
Inkabb mondjuk ugy, hogy neha olyat is meg kell csinaltatni az emberekkel, amihez nincs kedvuk. Ez ugyan az Agile-lal ellentetes (meg a Lean-nel is), es a hithubbje biztos fel is mond, de legalabb mukodik.
A tapasztalat az, hogy az Agile meg a Lean arrol szol, hogyha valamit meg kene csinalni, ami nem kod, akkor beszolnak, hogy nem vagyok eleg <aktualis mania>...
Tudod, gondolkozni az Waste, leirni a gondolatokat az meg nem Working Code...
Azért írtam, hogy amennyiben karban is van tartva. Ha ügyesen fejlesztenek, akkor minden feature előtt csinálnak egy koncepciót,
és a feature lezárása előtt még gyorsan átírják, amíg a fejben van, hogy ahhoz képest miben tértek el, és miért.
Hajamra kenhetem a függvények előtti pár soros blablát, ha arról nem lesz fogalmam, hogy mi merre hány méter a projektben vagy hogy egyáltalán mit is kellene tudnia.
A manager olyan dolgokat csinál, amit az átlag sw fejlesztő se nem akar, se nem tud. Lásd: idióta customer összevissza
kívánságait értelmes requirement formájába önteni, kapcsolattartani, összeszervezni az emberek munkáját, tartatni a
határidőket, átpriorizálni, összerakni a fejlesztési folyamatokat, hogy mindenki ugyanúgy csinálja a dolgokat,
kiverni az emberekből a tesztelhetőséget, stb. Ezek azok a munkák, amiktől az átlag fejlesztő sikítva menekül.
Azt ismerjük el, hogy idehaza még mindig azok vannak többen, akik arsz poétikája az, hogy "azért lettem menedzser, hogy kitapossam a beosztottaimból, amit a főnökeim tőlem elvárnak", mint akiké az, hogy "azért lettem menedzser, hogy a környezetből (ide értve a főnökeimet is) kitapossam annak feltételeit, hogy a besztottaimmal produkálni tudjam, amit a főnökeim tőlem elvárnak".
Bár személyesen az utóbbi években e téren nem panaszkodhatom (kopkopkop).
Azért ez így erős csúsztatás. Ennyi erővel azt is állíthatnánk, hogy idehaza még mindig azok vannak többen, akik arsz poétikája az, hogy "azért járok be, mert fizetést kapok", mint akiké az, hogy "azért járok be, hogy dolgozzak".
voltam mindkét oldalt, programozni egyszerű, akárhogy túlmagasztaljuk néha. egy leírt rendszerről van szó, amit mi alakítunk. az elmebeteg piaci viszonyok, a lehetetlen elvárások, az ezerarcú ügyfelek ehhez képest egy 1000 dimenziós játéknak tűnnek.
eddig egy programozóval volt dolgom, aki látta, hogy na srácok, ügyfél közelébe nem akarok menni, de hajlandó vagyok elfogadni hogy a sales-es 2x annyit keres mint én. nem mondom hogy így kell lennie, de azért kódolni közel se olyan háborús körülmények közti kínlódás, mint ügyfelezni, és vezetni
(megjegyzem a fenti rossz tapasztalatokat megértem, hogy miért vannak, de elfogandni nem tudom őket, csak mint sztereotípiát, ugyanis volt dolgom már jó vezetőkkel-managerekkel is, vannak akiknek én is fizettem, hogy vezessenek, mert tudtam hogy többre leszünk képesek vele)
Az a manager, aki software-projectet visz es sosem volt programozo, az kapja be.
Az architect programozo. Pont. Meg akkor is, ha nem ir eppen kodot. Ha nem programozo, akkor kapja be. Ha tul tavol kerult a kodtol, akkor nem architect, hanem egy folosleges figura, aki altalaban nem a valos problemakra koncentral, szoval duplan kapja be. :)
eleg frusztraltnak tunsz, nem akarsz setalni egy kicsit? Aztan meg ha az a temerdek ficko egyszer tenyleg bekapja, akkor meg sirni fogsz... bar ki tudja, lehet, hogy te mar be is kaptad, es csak a viszonzas hianya miatt sirsz, LOL...
Nem tudom, én ügyfelekkel is foglalkozok, és programozok is. Előbbiben is vannak nehézségek, de azért ha egy alapvető pozitív hozzáállás megvan, onnantól nem egy rocket science. Persze felelősséggel jár meg minden, de azért azt gondolom hogy a csak programozók egyértelműen többet érdemelnek, mint a csak "ügyfelezők".
Lehet nem egy témakörben ténykedünk, neked az ügyfeleiddel milyen foglalkoznivaló van, milyen tevékenység mellett? Én nem csak az időpontegyeztetés-termékbemutatás-termékádatás és hasonlókról beszélek, hanem például az ügyféligények felmérésére, ...
Szóval kérlek mondd el, hogy nálad mit takar az ügyfelezés, hátha nem egyről beszélünk.
Rengeteg kis ügyfelem van (és egy nagy, de azt most inkább hagyjuk), alkalmazásbolton keresztül vesznek programot, amellyel kapcsolatban gyorsan kell megnyugtató választ adni (bug esetén < 1 nap alatt megoldást nyújtani, egyébként valamit mondani hogy mikorra várható az adott improvement/feature). Végsősoron a lényeg, hogy jól érezzék magukat. Többnyire olyanok írnak, akik már fizettek, a fegyver a kezükben az, hogy ha nem elégedettek, akkor jól lepontozhatnak.
Ez ügyféligények felmérése kategória, de valószínű hogy másról beszélünk, minden munka, minden élethelyzet más...
Ettől függetlenül fenntartom, hogy egy alkalmazás fejlesztésében a programozó a kulcsfigura. és nem a manager, vagy a sales -es. Ezt csak azért akartam kiemelni, mert látom hogy általános tendencia kezd lenni (nem konkrétan rád vonatkozik) egyszerű munkásnak (mondjuk aranybányász) tekinteni a szoftverfejlesztőket, akik révén aztán lehet kaszálni...
Menedzser oldalról értem, de a saját munkámban az ügyfelek részéről tapasztalom a leszólást és néhány kérdés fontosságának lekicsinyítését a hozzá nemértésük miatt. Ez még egy dolog lenne, sokszor a baj inkább az, hogy nem bízzák rá a hozzáértőre a kérdést, hanem saját kútfőből akarnak olyan dologban dönteni, amihez nem értenek.
(értem hogy mire gondolsz az egyszerűsítésen, azt én sem támogatom, részben ezzel kell küzdeni az ügyfelek kapcsán, ők is ugyan úgy azt hiszik, hogy "hát csak rakj oda egy gombot", csak hogy egy kis rekurziót belevigyek :) )
más tevékenységben vagyunk, te egy kész terméket, amit saját terveid alapján készítettél, ajánlasz vásárlásra, és azt support-álod, fejleszted igények szerint (ha úgy látod hogy egyezik az iránnyal amit te akarsz csinálni). én jelenleg legtöbbször ügyfél ötlete-igénye alapján fejlesztek (hozzátéve az én meglátásaim, ha elfogadják a tanácsot), itt jóval több egyeztetés, jóval több probléma kezelés van, mintha elétolnék valamit, hogy na, ezt adnám el, tetszik vagy nem, mi kéne még bele. utóbbi esetén lehet, hogy tényleg nem kell annyi management munka, ezért is próbálok elmozdulni erre felé két termékemmel
egyébként alapvetés, hogy mindenki dolgozzon, és mindenkit ismerjünk el. és mindenki csinálja azt amit szeret. egy manager azért csinálja azt amit, mert szeretné segíteni a többieket (és magát) a célja felé, azzal, hogy szervez, és optimizál, és intéz, és figyel. egy programozó meg kódolni akar, nem ügyfeleket akar látni, nem is feltétlen üzleti oldalt, csak problémákat, logikai feladványokat, szerintem. egyik sem rosszabb mint a másik, csak van két tendencia:
- egyik amiről te is írtál, a kódert szakmunkásnak nézni, mert hogy hát minden csak 2 kattintás - nem látva, hogy legtöbb esetben, ha csak kicsit is, de egyedi gondolatok kellenek, ezért ez szellemi termék előállítás, és kreatív munka, közelebb áll a design-hoz, írói tevékenységhez, mint a villanyszereléshez (nem villamos tervezést írtam, tessék figyelni)
- a másik, hogy az éremnek két oldala legyen, amikor a kóder azt mondja, hogy nélkülem semmire se menne a manager, mert nem lenne mit eladni (nem állítom hogy te ilyen vagy). ez részben igaz, de a legtöbb programozó messze nem tudna annyit (ha egyáltalán) eladni, mint amennyit akár egy középszerű sales-essel teszi. területfüggő, hogy mennyire van erre szükség, illetve sok programozó alkalmazottként szeret dolgozni, ezért ezt nem is látja (vagy akarja látni), téves adatokra építve azt mondja, hogy ááá minek ide a marketinges és a manager
"és kreatív munka, közelebb áll a design-hoz, írói tevékenységhez, mint a villanyszereléshez (nem villamos tervezést írtam, tessék figyelni)"
Ez mondjuk tipikusan olyan dolog,a mivel szeretik magukat a koderek onamitani: van rengeteg szabvanyos megoldas es/vagy rengeteg kesz pattern/ajanlas adott konkret problemakra. A problema viszont ezzel az, hogy:
- tul sok van beloluk
- ugyanarra a feladatra is tul sok alternativa van
- sok koder szereti azt hinni, hogy neki most muveszkednie kell alhelyett, hogy a problemat megoldana a -szituaciotol fuggoen- "szabvanyos" modon.
Ebbe sok esetben beletartozik az is, hogy egyaltalan betartjuk a hasznalt keretrendszer konvencioit...
igazad van abban, hogy nem kell művédszkedni, de ahogy te is mondtad, van x+1 megoldás egy problémára, és általában egyik sem pont arra az esetre van, amire neked kéne, vagy kicsit változtatni kell rajta, vagy nagyon átgondolni melyik lenne a jó megoldás...
ezt fejeld meg azzal, hogy milyen szinten változnak a felhasználási szokások, a technológiák, a fejlesztési irányok, én erre értettem azt, hogy nem villanyszerelés, hogy biztosíték az biztosíték legyen. de tény, vannak már best practice-ek, és pattern-ek a megvalósításra, de még akkor is mérlegelni kell erősen, hogy mit hogy és merre alkalmazunk
Mondjuk engem mindig lehangoltak azok a programozók (és munkáik), akik mérnöki munkának tekintik a munkájukat, és nem művészetnek...
A "művészkedésnek", amiről te beszélsz, van egy pejoratív felhangja, és igen, van aki azt csinálja, és az nem túl jó.
Ha viszont valaki _művészetként_ űzi, az egész mást jelent... Nem művészkedést, és nem is mérnöki munkát. Művészetet.
És mennyibe kerül, és mennyi idő alatt készül el? :) (Sagrada Família - 1882->2028, de ahogy a válságot meg a spanyolokat nézem, inkább 2040 a reális cél :))
Hát mint minden hasonlat, ez is sántít :P
Egy művészi szemmel felépített szoftver spórolást jelent hosszútávon, mert könnyebben karbantartható és fejleszthető kódot eredményez.
Karbantartható és fejleszthető kódnak mi köze a művészi szemmel felépített szoftverhez? Szerintem semmi. Pont, hogy a mérnöki munka (megfelelő nyelv, framework,
design patternek, standardizált fejlesztési folyamatok, stb.) által lesz lehetőségünk arra, hogy a kód karbantartható és fejleszthető legyen.
Azért egy Gaudi épület karbantartása rettenet nagy szívás.
Van olyan kódom, amihez fel van írva a teljes design decision tree, kiindul 3-4 user requirementből, hozzácsap még 5 technical requirementet, és fraktálisan kinyílik, 6 A4-es oldal, a végén kijön kb. 10-15 000 sornyi kód.
DE: jött persze az orosz programozó miután én leléptem, és belerondított. Nem igazán érdekelte az, hogy ez mennyire művészien van felépítve. Pedig az még logikus is volt.
Képzeld azt, hogy a kódodat, miután leléptél a cégtől, egy igénytelen értelmi fogyatékos fogja karbantartani. Tervezd meg úgy, hogy ennek ellenére jó helyre helyezze be a módosítást. Na, ez a művészet.
Na de épp ez az, hogy a művészi érzékkel megtervezett, szimmetrikus csodakód elhasalt a karbantarthatóság követelményén
az első olcsósított jómunkásemberrel történő találkozás során.
Mit csinál egy "olcsósított jómunkásember" két vasgolyóval egy üres szobában?
...
Az egyiket elveszíti, a másikat elrontja.
Szerintem annyi az egész csel az egészben, hogy ha egy kódot X szintű programozok írtak, akkor az X szintűek kell karbantartsák. Alacsonyabb szintűek nem értik meg, a magasabb szintűek meg nem valószínű, hogy látni akarjak azt a gányolást...
Azt az X szintet már a projekt elején úgy kell kiválasztani, hogy legyen elegendő utánpótlás. Tökmindegy, hogy hova teszed a mércét, utólag már nem módosíthatsz rajta. Ha nem kapsz időben utánpótlást, akkor az a projekt halott.
Arra a fajta művészi hozzáállásra, amiről a kolléga fent beszél, nem igazán van se igény, se
szükség, sem pedig lehetőség.
Munkaadóként többre megyek egy olyan fejlesztővel, aki kevésbé zseniális, de normális, mások által követhető munkát ad ki a kezei közül, mint a művész/zseni/stb.-vel, aki bár nagyon gyorsan dolgozik, de ha bármi történik vele (otthagyja a céget, elüti a villamost, stb.), akkor ember nincs, aki megértse, hogy mit miért csinált (ugyanis a dokumentálás nem az erősségük, hiszen ott van minden fejben), és ezért az egész projekt bármikor veszélybe kerülhet.
Ez nem azt jelenti, hogy gépelő droidokra van szükség, kreativitásra igen, viszont korlátok között. A korlátok nélkül szárnyalunk kutatási témákban tökéletes, ipari termelésben nem igazán.
Nem erről beszéltem...
Írtam is, hogy egy művészien felépített kód könnyen megérthető és áttekinthető.
Az mondjuk biztos, hogy a nyelv egy korlát az információáramlás számára.
Továbbra sem értem a művészi szóhasználatot. Egy jól felépített kód,
így igen. De hogy ennek mi köze van a művészethez? Legyen rendesen,
normálisan megcsinálva, és ennyi.
Én értem, hogy miről beszél, csak egyfelől tényleg nem fenntartható, másfelől általában rossz irányból indítják.
Valszeg Vitruviusi, vagy Alexanderi szimmetriákról beszél. A Vitruviusi embert mindenki ismeri, az egy illusztráció ehhez. Az Alexanderi szimmetriákról képekben itt és itt lehet nézelődni.
Ezeket hogy hogy lehet kódban alkalmazni, arról Coplien írt itt.
Félreértés ne essék, lehet ilyet játszani, csak azt tessék megérteni, hogy nem lehet az EMBERT kihagyni a rendszerből. Ott bukik az egész. Márpedig itt van felhasználó és karbantartó, és úgy kell megteremteni a dolgot, hogy ezek jól érezzék magukat ezekben a terekben, különben szart se ér.
A szép kód jellemzője, hogy nem nagyon tudják összebaszni. Szerencsére az én kódomat se tudta az orosz, letört róla darabokat itt-ott, de az architektúrája - amennyire legutóbb, másfél évvel a kiadása után néztem - ugyanaz. Ez olyan mint amikor betonnal egészítették ki a Pantheont. Mondjuk rossz kódra is igaz ez sokszor...
De abban teljesen igaza van Alexandernek, hogy mindez csak akkor működik jól, ha jó irányból indítjuk: egy kódnak elsősorban a felhasználó céljainak, másodsorban a várható változások eltűrésére kell tudnia felkészülnie. Ezekre kell építeni az univerzális elveket, nem lehetnek magukban.
Azt azért hozzátenném, hogy még zenét sem azért ír az ember, hohgy önmagában álljon. Különböző motivációk vannak, pl. valaki azért, hogy szívesen hallgassa, van aki azért, mert jó érzés írnia. Van aki másoknak, egy befogadó célcsoport számára akarja mutogatni, és olyan is van, aki azt akarja, hogy minél többen akarják hallgatni (akár azért mert sok pénzt akar vele keresni, akár más okból). Csak azt mondom, hogy a művészetnek általában is van céja.
mi lenne, ha az emberek olyan dolgokat csinálnának, amikkel céljuk is van? pl. ha egy programozó művészkedni akar, akkor csinálja, még a végén jó is kisülhet belőle. de persze sokan vannak, akik tudják a tutit, ezért is olyan sikeresek, és ők nem kezdenek el művészkedni. és sok érdekeset létre is hoznak, vagy nem.
az amit ma standardnak, meg patternnek hívunk, az egyszer egy művészkedő baromsága volt egy próbálkozónak. értem én, hogy ezt nem egy kkv-nál kell megcsinálni, de amúgy mit is tud csinálni egy kis cég, ha előre akar kerülni? csak csinálja ugyan azt, mint mindenki más?
Az a baj, hogy amit te művészkedésnek hívsz, azt mások mérnöki munkának. A művészet az valami olyasmi, ami valahol zseniális, de megismételhetetlen, befejezett, specializált. A design patternek ehhez képest megismételhető, adott feladathoz igazítható, általános megoldások, egyedül a zsenialitásban hasonlítanak a művészetre. A mérnöki munka nem zárja ki a kreativitást, sőt! Csak vannak korlátok, amiket nem érdemes átlépni, mert hosszú távon az csak ront a helyzeten, pl. nem kell újra feltalálni egy design patternt csak azért, mert nem tetszenek a metódusnevek.
Az építészmérnökök is csodálatos épületeket tudnak tervezni, de ők sem léphetik át a statika törvényeit, mert ha később összedől a ház, abba emberéletek kerülhetnek.
Csodálatos hogy sikerült elferdítani a mondandómat.
Előlről: A problémám az, hogy sokan lelketlenül végzik a munkájukat, pusztán megoldandó feladatokat látnak, nem pedig alkotnának.
Ertem, szoval ha valaki kap egy feladatot, azt lespecifikalja, tervez hozza egy megoldast, majd vetve az ajanlasok, szabvanyok, best practiclek, es patterneknek megfeleloen (amely tengerben kiigazodni mar onmagaban nem keves kreativitas kell szvsz.) elkeszit egy szoftvert, neadj'isten teszteli is, sot mi tobb, mindezt orommel teszi, akkor a tisztelt mernoki munkat vegzo ember...?
Azt én nem tudhatom. Lehet hogy művész. Ismernem kéne az illetőt, és a munkáját, általánosságban meg nem mondhatom.
Szerintem ki kellett volna derüljön (hiszen többször leírtam), hogy a problémám az. hogy sokan minden lelkesedés nélkül hidegvérrel megoldanak problémákat úgy ahogy tudnak. Az biztos, hogy más a szótárunk, de valahogy úgy tűnik, te valamiért ezt magadra vetted, pedig azt gyanítom hogy rád pont nem is igaz ez. Talán az nem tetszett, hogy a mérnök szót húztam le, valószínűleg más a szótárunk.
Mindegy, a problémám továbbra is áll, és valószínűleg veled nem van, és tényleg nem értem miről szeretnél meggyőzni.
De mondok egy példát: Itt a hupon egyszer kiakadtam X szoftverre. Erre valaki azt írta, hogy hát úgy kell rá tekinteni mint egy eszközre, a megfelelő célra ha alkalmas, tök mindegy élvezetes-e használni, meg kell oldani, csókolom. Na az ilyenekkel lehet kikergetni a világból: Könyörgöm, ha valakinek valami a munkája, akkor lelkesedjen már, ne csak a feladatot akarja letudni.
Na mindegy.
Ez az "a manager" elég furcsán hangzik. Egy cégnél több tucatnyi manageri ág van, pl. HR, Facility, IT, PR, pénzügyi és persze cégvezető. És ehhez jönnek az R&D közeli manageri funkciók. Pl. product manager (vagy Scrum esetén Product Owner), aki magáért a termékért felel, meghatározza, hogy mit kéne fejleszteni. (Tehát ő a vevő fele a fő kapcsolattartó. Lehet belőle több is, pl. web szerver terméknél maga a HTTP kiszolgáló, beépülő nyelvi modulok stb. felelősei.) A project manager a termék fejlesztésének menetét szervezi (hogyan, Scrum esetén ez a szerep kicsit szét van kenve).
A line manager (csoportvezetőféle) az R&D talán legizgalmasabb managere, a szervezet hosszútávú hatékony működtetésén dolgozik ezer feladatkörrel. Pl. leszervezi a munkákat a project managerrel, irányíthatja a csoport napi munkáját, az emberek karrierjét egyengetheti a cég érdekében (de ezzel rövid távon a csapata ellenében is akár), fizetést emel, felvesz, kirúg, kinevez és mindent próbál megadni a csoportnak, hogy dolgozni tudjanak kompetencia managementtől gép beszerzésen át a mindenféle adminisztrációs vackokig. Ez a sok dolog akkora teher lehet, hogy jobb esetben egy hatalommal nem rendelkező csapattagra hagyja a csoport napi működtetését, pl. Scrum esetében a Scrum Masterre. (A Scrum nem feltételezi a line management létezését, mint ahogy egy cég igazgatóét sem. Ők Scrum szempontból ún. csirkék.)
A feladatkörökből látszik, hogy nem feltétlenül a kegyetlen nagy kódereknek vagy architekteknek kell a manager pozícióra átülniük. Legfőképp nem a line manager pozícióba. És az is látszik, hogy van más, konkrét, hasznos feladata egy managernek.
Hozzászólások
Es igen, ahogy irja ez mashol igy van sajnos. Elkezdtem olvasni es megallapitottam, ezt akar tolunk is irhatta volna valaki.
A sok meeting a sok doksi - de persze amire szukseged lenne az pont nincs - a "It is not what you do, it is what you sell." meg a "I spend most of my time trying to figure out how others’ uncommented/undocumented code work, debugging strange things and attending daily meetings. " egy ido utan demotivaloak.
Jah a copy-pasten jot rohogtem. Hanyszor lattam, hogy egy-egy hasonlo funkciot cpoy-pasteeltek, persze a hibakkal egyutt.
A masodik pontrol pedig az jutott eszembe, amikor a managereink - hogy sporoljanak az idovel - azt kertek a csapatunktol, hogy a betervezett test caseek szamat csokkentsuk 30%-al, ugy hogy technikai indokuk erre nem volt, csak a "sporolas".
Hja, pont a blogban leírtak miatt egyre inkább az a véleményem, hogy a nagy (neadjisten multinacionális) cégek hatékonysága kizárólag a méretből fakadó lobbi és adóoptimalizálási lehetőségekből adódik.
Az előző munkahelyemen abban a luxusban volt részem, hogy nem volt "menedzserem", hagytak minket dolgozni, úgy, ahogy mi azt jónak láttuk (a specifikáció kidolgozásától kezdve a késztermékig mindent). És ez komoly motiváció, bizony sikerült is jó szoftvereket csinálni. Azonban azt látom, hogy sajnos ritkaság az ilyen.
+1
Lehet, hogy ennek az eredménye a használhatatlan, hibákkal teletűzdelt szoftverek?
-----------
"640GB sokmindenre elég"
Kis, 5-10 fős teamnél tényleg felesleges tud lenni a sok menedzselés, de ahol több százan dolgoznak a kódon, ott nem lehet "átugrom a Józsihoz és megbeszéljük mi legyen"-t játszani.
Itt arról van szó, hogy pont a sok (értelmetlen) menedzselés öli meg a fejlesztést. Magának a menedzselésnek van értelme, ha jól csinálják. Én pl kifejezetten örülnék neki, ha nem engem pingelne mindenki, hanem lenne valaki, aki fogadja a beérkező kéréseket, rendszerezi és nem szakít félbe állandóan. De ez csak egy utópiának tűnik sajnos.
-----------
"640GB sokmindenre elég"
Mégis milyen kód az amin több százan van értelme dolgozni?
(úgy értem, miért nem lehet több egymástól függetlenül működő subprojectre felosztani?)
foleg, ha jozsi oroszorszagban vagy spanyolban van :D
--
NetBSD - Simplicity is prerequisite for reliability
a daily meeting rendszere borzalmas... legalább ingyen sört adnának, akkor lenne értelme....
A daily meetingeknek van értelme, ha jól csinálják: max 15 perc, hogy a csapaton belül mindenki tudja, hogy ki mit csinál, és hol tart.
Gondolom ti nem jól csináljátok, ha azt mondod, hogy borzalmas.
+1
Sokat tud segíteni.
Óóóó 15 perc is tud olyan lenni, mintha zombik ennék ki falatonként kis műanyag kávéskanállal az agyadat, közben meg a háttérben a buckalakók kórusa szólna.
ha jól csinálják
Ez fontos. :)
afair az agyban nincsenek idegvégződések... úgyhogy annyira nem lehet para :D
--
CyclonePHP
Mindig csak ez az ellenszenves piszmogás a tényekkel.... :)
A saját munkádból indulsz ki, ez gond. Próbáld általánosítani, mert a jelenség is az sajnos. Nem a hogyancsinálddal van a baj (azzal is lehet egy alkalmatlan vezető esetén), hanem azzal, hogy mikorcsináld vagy mikornecsináld.
Pl. Ha a fejlesztőknek ki van adva egy határidős meló és egészen konkrétan meg van határozva egy hétre előre, kinek mit kell csinálni (vagy esetleg ki vannak alakítva a 2-3 fős fejlesztői csoportok, akik folyamatosan egyeztetnek egymással) akkor hullára felesleges felállítani őket a kódtól és az üveges tekintetű embereket átrángatni egy másik világba, aztán meg visszatuszkolni őket.
A meeting oké, de a daily nem oké.
https://pbs.twimg.com/media/BGL4u-eCQAA5yNe.png
Amúgy a daily standup is jó, persze nem úgy, ha keresztbe vágja a napot.
erosen ferdit, 3 ora alvas van csak a kepen, de van benne igazsag
--
NetBSD - Simplicity is prerequisite for reliability
+1
bár igazából tényleg vannak olyan kódergépek, akiknek elég a 3-4 óra alvás..
es meddig eleg? egy-ket hetig? egy honapig?
--
NetBSD - Simplicity is prerequisite for reliability
az elmult 8-10 évben majdnem végig :)
Na meg azért az átlagember is kezd már hullani az utolsó pár órára.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Még a daily is oké, ha oka van. Ok pl. az lehet, hogy a góré ismeri az embereit, és tudja, hogy ki az, akit egy hétre egyedül lehet (kell) hagyni, és a hét elteltével nem hümmögés meg kifogás lesz a státusz, és ki az, aki tök jól megcsinálja a dolgát, de csak akkor, ha arról naponta be kell számolnia.
Aki az egész társaságot az utóbbi módon kezeli, az nem tud saját csapatában disztingválni, vagyis legalább részben tévedésből kapja a fizetését.
Ez azért picit magyar virtus is: mi szeretjük felosztani a munkát egymást max tévedésből fedő/összefüggő részekre, és nem igazán vagyunk kiváncsiak arra, hogy a másik mit csinál.
Vezetőként ezt sokféleképp meg lehet oldani, de az egy értelmes és jogos vezetőségi igény, hogy legyen egy ritmusos (minden nap ugyanakkori) minta arról, hogy hol is tartunk, mert abból lehet látni a hümmögős részeket, amikor Józsi vagy külső vagy belső okok miatt meg van akadva.
Volt olyan team, ahol magunktól csináltuk a napi meetinget, és volt olyan team, ahol én is rühelltem róla beszélni. Minek? Senkit nem érdekel, senki nem szeretne beleszólni és senki nem fog hozzátenni.
Szóval önmagában a standup még nem működik. Ahhoz kell az is, hogy érdekelje / érdekelt legyen a másik abban, hogy mindenki másét végighallgassa, hasson az életére.
Ez borzalmas, átéltem ilyet, menekültem is a cégtől. Egy produktív, kreatív embernek agyhalál a sok értelmetlen megbeszélés (amiknek a fele csak szimpla fontoskodás). A kommentálatlan, doksi nélküli kód szintúgy. Pláne, ha évek óta megbúvó redvás hibákat kell benne javítani. Olyan kódban, amit vki egyszer elkezdett C-ben írni, aztán mindenki, aki az utóbbi 10 évben hozzáírt, a saját coding style-t használta, C++-ban is beleirogattak, stb. ahogy épp tetszett. Egymás mellett élő párhuzamos megoldások ugyanarra a problémára (mert pl. az egyik fejlesztő nem vette észre, vagy nem érdekelte, hogy már létezik egy megoldás, ő megírta a sajátját). Multiknál még külön szép, amikor a külföldi kollegák szó, kérdés, értesítés vagy code review felkérésé nélkül piszkálnak bele a mi kódjainkba is, mi meg ha fordítva így teszünk, letolnak...
Dolgozam eddig két multinál, és azt láttam, hogy a kívülről csillogó sw-ek belülről rendszerint rohadnak, de ahogy a cikk is írta, nem abból lesz a pénz, ha szép a coding style meg refaktorálják a kódot, hanem abból, ha van (új) feature a sw-ben és azt el lehet adni. A sw fejlesztő feladata meg az, hogy oldja meg, ahogy tudja (meg ahogy hagyják neki). Marketingest, ügyfelet, tulajdonost csak a bevétel érdekli és vhol ez is megérthető.
Van, akinek bejön ez a világ, van akinek nem. Láttam sok olyat, akinek elég volt napi effektív két óra munka, a maradék hatban (amiből egy óra ebédszünetet tartott) meg remekül elvolt a megbeszélésnek nevezett szájtépéseken, kávézgatásokon, Xboxozáson és egyéb multis modoroskodásokon.
Hülyének is néztek, amikor eljöttem egy kis magyar céghez, hogy alkothassak. Előtte is magyar cégnél voltam, most is, és a szakmai fejlődésem ezekben az időszakokban volt csak jó. A multiknál megtanultam néhány dolgot, hasznos volt, de ha lehet, elkerülöm őket.
+sok
ezert nem lettem en foallasu fejleszto... ha van valami erdekes projekt azt elvallalom de hogy ilyen vizfeju cegeknel dokumentaljam a ganyolast azt mar nem
A'rpi
+1
Nagyon egyetértek!
Nyolc(!) honapot voltam kepes "klasszikus" multinal dolgozni.
Nyolcat. Ennyi turelmem volt a hitegetessel, hogy "most mar lassan lesznek nagyobb hozzaadott erteket kepezo munkak."
Aztan jott a telco, es megmutatta egy ember, hogy hogyan tolunk be egy Netscalerbe webes feluleten(!) egy SSL tanusitvanyt.
En meg leleptem a francba.
Szintén zenész. 10 hónap után majdnem kaptam fejlesztést, aztán az utolsó pillanatban mégis vissza akartak rakni supportra. De nem raktak mert felmondtam :P
CyclonePHP
... és hány embernek nem lenne munkája, ha ezek a dolgok nem így lennének ;)
És ha jobban belegondoltok, ez nem is iparági specialitás.
nem iparági specialitás, ahogy az sem, hogy a legtöbb ember munkája tényleges értéket nem állít elő, majdnem minden 2 főnél összetettebb csapatnál vannak gyertyatartók, vagy pótemberek, hihetetlen potenciál van elpazarolva így
Amellett, hogy a nagy cégeket nem szeretném védeni, a nagy cégek alkalmazottainál két sérelmet ott látok lenni a metszetben:
- sokat kéne dokumentálni az anyagot,
- nincs eléggé dokumentálva az anyag.
Nem mondom, hogy nem érzek együtt, de...
+1
És tényleg, ezzel a két véglettel lehet találkozni, egyik nagy cég ezerfajta doksit csináltat mindenhez (a programozók többet foglalkoznak diagramokkal mint kódolással kb.), másik nagy céget meg abszolút nem is érdekli, hogy mi az a dokumentáció kb., az arany középutat ritkán látni.
Ott van sok helyen az arany középút is: megy a mismásolás, ha le kellene doksizni valamit, de ugyanazok az emberek pampognak, ha valaki más kódjához nincs leírás. :)
Ez egy negyedik eset, "az aranyközépúttal párhuzamos rossz út", ahol csak a doksik mennyiségének az összege optimális, de ez az összeg rossz összetevőkből épül fel.
Ezt próbáltam kevésbé offenzíve körülírni fentebb.
Én már nálunk is felvetettem, hogy nem lehetne azt, hogy fejlesztés közben szépen kommentezem a kódomat, pl odaírom, hogy mit csinál, majd a végén 2 kattintással generálok belőle fejlesztői doksit? De nem. Pedig hasznos lenne, feltéve, hogy egy if elé nem azt írom oda, hogy "ha a feltétel teljesül, lefuttatjuk a kódot" :)
-----------
"640GB sokmindenre elég"
Ahogy én most látom, igazából nem kód szintű doksira van szükség, hanem koncepcionális doksira, hogy működik az egész
rendszer, milyen részei vannak, ha új modult kell csinálni, akkor azt hova kell rakni, hogy működjön, illetve ha nem triviális
trükközések vannak, akkor azok miért történtek, mi volt az oka, és hogyan működnek. Néha még hasznos, ha le van írva, hogy
egy metódus mit csinál, de ennél bővebb doksira (a nemtriviális eseteket kivéve) szerintem nincs nagyon szükség.
"Ahogy én most látom, igazából nem kód szintű doksira van szükség, hanem koncepcionális doksira, hogy működik az egész
rendszer, milyen részei vannak, ha új modult kell csinálni, akkor azt hova kell rakni, hogy működjön"
Hatalmas +1. Mindenféle kódból generált ADI doc, mint "dokumentáció" csak illúzió.
Na meg az se hátrány, ha van funkcionális specifikáció. Merthát az sem mindig szokott lenni. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Főleg ha a funkcionális specifikációban a menet közbeni változásokat is beleírják :)
éppeszű fejlesztés előfeltétele kéne legyen egy normális, "VÉGLEGES" terv, ehelyett legtöbb helyen foltozás megy, kis vagy nagy cég, az biztos, hogy 99%-ban nincs határozott irány
Azért az van ám, hogy a puding próbája az evés.
Hiába szeretnél te "végleges" specifikációt, a delikvens nem igazán tudja, mit kér.
Ráadásul az ismereteink nem úgy vannak, hogy először ismerjük a rendszer A, B és C modulját aztán így megyünk tovább, az úgy megy, hogy felbontást látunk, és a homályos képből próbálunk kislilabizálni kontúrokat.
Lehet, hogy lónak tűnt de közelről vaddisznó.
A megoldás erre szerintem amúgy a felületprototípus. Tegyél le elé egy cuccot, ami totál úgy viselkedik és úgy néz ki mint a végleges, csak baromira nincs mögötte backend, és kizárólag memóriába dolgozik. Ez lehet hotspotokkal körbespékelt powerpointtól kezdve flashen át HTML5-ig bármi.
Emellé kb. olyan folyamatábrákat kell csinálni, amik gombokat kötnek össze képernyőképekkel.
Ha ezen kiszórakozta magát, mert ezt érti, és ezen egyszerűen tud vitatkozni, akkor már nem fog mindenféle marhasággal traktálni. Akkor már csak az ötletembereket kell leszerelni, amire a jó fejlesztői válasz "it'd take too much time. Perhaps in the next version".
Azt sose feledd, hogy mindenki másnak a UI A rendszer. Édesmindegy, milyen csodálatos backend kódot írsz, a User Interface az egy interfész, elrejti a mögötte lévő implementációt, az user szemmel nem érdekes.
Szóval a lehető legolcsóbb módon csináld meg a UI-nak egy kezelhető változatát, vedd rá őket hogy nyomkodják végig (pl. a testplaneket hajtsák rajta végig a managerek), hagyd, hogy kivitatkozzák magukat rajt, és majd néhány hét múlva amikor már nem hallani napi 3 change requestet a prototípuson, kezdd el a tényleges implementálást.
Nekem néhány cégnél bevált.
(alapvetően nem a közvetlen ügyfél számára való fejlesztésre értettem a tervtelenséget, hanem a "tömegtermelt" project-eknél is látok hiányosságokat ilyen téren, pedig ott elvileg nem 2 perce ismerték fel az igényt, és nem 5 perce kezdték el kitalálni a megoldást)
megerősítettél abban, hogy jó irányba haladunk, csak ez egyúttal azt is jelenti, hogy a fejlesztési folyamat hosszabb lesz, és az árakat részben meg kell emelnünk (amit amúgyis megtennék, mert nem az árversenyben akarok részt venni)
a másik, hogy van olyan ügyfél, akinél még ez se elég, az, hogy a fejlesztés alatt álló felülethez folyamatos hozzáférése volt, és 2-3 naponta tesztelte, még ez sem volt elég, a végén minden további nélkül kért globális változtatást, na ott hangzott el a "jelenlegi változatra szerződtünk, következő változatban benne lehet."
Amit a hozzászólásból kivettem, mert így is túl hosszú volt: az ügyfél nem a júzer. Az ügyfél (manager) soha nem fog leülni élesben kattintgatni a szoftvert, ill. a legritkább esetben.
Édesmindegy, hogy ez a megrendelő belső, vagy külső: amikor az "ügyféllel" beszélsz, azon rendszerint karóra, ing, és farmer vagy vászonnadrág lesz.
Cserébe, mint a gyerek, hisz a történetekben, és ha azt tudod neki mondani, hogy odavittük a Béluskához, akinek ezt majd használnia is kéne, és az azt mondta, hogy neki ez így jó, meg a Marika is azt mondta, aki szintén használni fogja, akkor le tud nyugodni.
Minden projektemhez iszonyat erőkkel szoktam usereket vagy user-pótlékokat keresni: user-pótlék az, aki vagy a szoftver konkurenciáját használja, vagy valami más okból az utóbbi 1-2 évben volt olyan élethelyzetben sokat, ahol a szoftver jól jött volna neki. Odaadom neki, és megfogalmazok egy célt (pl. térképes appnál találd meg a hotelt ahol tavaly nyaraltál, mittom), aztán nézem ahogy végigbukdácsol (és nem segítek neki a szoftver használatában).
Tömegszoftvernél ez amúgy könnyebb, gondold meg amikor vegyészeti szoftverhez kerestem ilyet...
Aztán már csak a managerek meggyőzése van hátra, hogy ezek hadd lássák a prototípust, lehetőleg előbb, mint ők és ne csak a végleges szoftvert mutogassuk meg.
Mutatok egy példát: egy kisprojekten egy nyomda volt az ügyfél, és diplomarendelő app kellett neki. Hülye volt és kapálódzott, hogy olyan kell, amit ő kitalált magának. Erre készült ez a doksi.. Ezek FB, GTalk, Skype chatek felékezetesítve kb, és a "na jó, elegem van" pillanattól kezdve 1-2 órába került összerakni (fb ismerősökön végignéz, ki diplomázott legutóbb, kapcsolatot felvesz, kérdéseket megfogalmaz, beír, összegyűjt, alap sablonba berak, csók). Kész szoftverre pedig a tapasztalat szerint a videó a jó.
Működik.
Persze hülyék mindig voltak és lesznek, de azért teljesen tehetetlenül nézni se szabad szerintem.
'Hiába szeretnél te "végleges" specifikációt, a delikvens nem igazán tudja, mit kér.'
Persze, hogy nem tudja, hogy mit kér, hiszen nem ritkán a saját tisztázatlan folyamataikra szeretnének informatikai megoldást, mondván, hogy a számítógép mindent megold -- aztán jön a döbb, amikor a rendelkezésre álló specifikáció alapján elkészült valami nem támogatja a káoszt.
mondom a probléma gyökerét: a gép nem intelligens, ők meg azt hiszik.
bővebben: az van, hogy aki papíron, gép nélkül nem tudja szervezni a cégét, megoldani a problémáit, az géppel se fogja. hiába az ajánló algoritmus, meg a CRM és a notification, ezt akkor csinálja a gép, ha van mögötte logika. az üzleti logika, aminek a program csak egy (ahol lehet) automatizált változata. ha nincs logika, nincs mire programot írni
hogy miért van a tévhit: mert elvetemült marketingesek eladják a saját (vagy akár más) logikájuk alapján összerakott programot úgy, hogy "új vevőket hoz", közben nem.
hogy miért van még: mert a legtöbb kivitelező fél azt mondani az ügyfélnek, hogy nem elég a terv amit elmondott, érzi az ügyfél feszültségét, bizonytalanságát, és erre jelenleg nem szoktunk rákérdezni
jó látni, hogy ezt a problémát a cégméret eszetlen növelése se oldja meg :)
"A megoldás erre szerintem amúgy a felületprototípus. Tegyél le elé egy cuccot, ami totál úgy viselkedik és úgy néz ki mint a végleges, csak baromira nincs mögötte backend, és kizárólag memóriába dolgozik."
Ja, ez elvben nagyon jó irány. Csak mivel neki a felület az UI, ezért ha lát egy teljesen jó UI-t, akkor azt hiszi, hogy a program már készen van. És mondhatod neki a jéghegyet, hogy a 90%-a a felszín alatt van, ő onnan kezdve azt hiszi, hogy a program készen van, és te csak az idejét és pénzét lopod.
Nem mindig, de sajnos sokszor így van.
"principles", na nekem is ez hiányzik midnen programnál, hogy oké, hogy egy modult kódsoronként értelmezni tudok, de ha nem tudom hogy hol töltődik be, el kell indulni a program indulásától, és kb. x000 sort át kell nézni, mire kiderül, hogy hja, tehát ez a globális változó erre van. ahelyett, hogy írnának egy leírást arra, hogy na, ezt kapja meg minden modul
pl. ez a leírás a legtöbb opensource cuccnál amivel dolgom volt annyira hiányzik, hogy a végén már mindenki beledobja a saját kódját inkább, és el is veszik az alapötlet, néha újraírásoknál megint előjön, de gyorsan nyoma vész
(ha most valaki azt mondja, hogy design patterns az elviekben jó irányba gondolkodik, csak nem futott bele a gyakorlati alkalmazásuknál lehetséges többszáz "alváltozatba")
A koncepcionális doksikkal az a baj, hogy nem fogod minden esetben előkeríteni, hogy mik az éppen aktuális koncepciók :)
-----------
"640GB sokmindenre elég"
Akkor azt az embert, aki így esik neki egy projektnek - és van dok. hozzá - nagyon gyorsan ki kell baszni a csapatból jó messzire, mert ő lesz az, akinek a kódját 3x annyi idő lesz karban tartani.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
A dokumentációkban az a baj, hogy nagyon kevés helyen csinálják jól. Vagy nincs, vagy van, de túladminisztrált a rendszer, a doksik változnak, a koncepciók nem az ésszerűséget követik etc.
-----------
"640GB sokmindenre elég"
Erre viszont nem az a megoldas, hogy akkor konstataljuk, hogy ezvan, hanem keresni kell ra megoldast.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
az, hogy valami szar, nem jelenti, hogy lehetne jobb is. Kicsit olyan ez, mint az energia. Vagy Sain-Márton Nincs királyi út! című műve.
Talán tényleg nem létezik gyors, egyszerű, hatékony etc. mód tervezéshez és dokumentáláshoz.
Puppy linux felhasználó
Inkabb mondjuk ugy, hogy neha olyat is meg kell csinaltatni az emberekkel, amihez nincs kedvuk. Ez ugyan az Agile-lal ellentetes (meg a Lean-nel is), es a hithubbje biztos fel is mond, de legalabb mukodik.
Az agile világában nem lehet olyat csináltatni, amihez az embereknek nincs kedvük?
A tapasztalat az, hogy az Agile meg a Lean arrol szol, hogyha valamit meg kene csinalni, ami nem kod, akkor beszolnak, hogy nem vagyok eleg <aktualis mania>...
Tudod, gondolkozni az Waste, leirni a gondolatokat az meg nem Working Code...
A munkakerülés nem újkeletű dolog, csak most másra hivatkoznak az emberek.
Azért írtam, hogy amennyiben karban is van tartva. Ha ügyesen fejlesztenek, akkor minden feature előtt csinálnak egy koncepciót,
és a feature lezárása előtt még gyorsan átírják, amíg a fejben van, hogy ahhoz képest miben tértek el, és miért.
Ezzel pont az a baj, hogy legtobbszor semmi masra nincs szukseg szinte, csak exmaple-okre.
Ez nem dokumentáció.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mi?
-----------
"640GB sokmindenre elég"
Hajamra kenhetem a függvények előtti pár soros blablát, ha arról nem lesz fogalmam, hogy mi merre hány méter a projektben vagy hogy egyáltalán mit is kellene tudnia.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
At the end, you are working for your manager’s and their managers’ paychecks.
És ez mennyire igaz egy multinál. Még fejlesztőnek sem kell lenni hozzá.
... sőt, még csak multinak sem kell lenni hozzá.
Ez azért elég demagóg szöveg. A vezetők munkáját is el kell végezni, ha ők nem lennének, akkor a programozó se tudna dolgozni, mert nem lenne hol.
+1.
A manager olyan dolgokat csinál, amit az átlag sw fejlesztő se nem akar, se nem tud. Lásd: idióta customer összevissza
kívánságait értelmes requirement formájába önteni, kapcsolattartani, összeszervezni az emberek munkáját, tartatni a
határidőket, átpriorizálni, összerakni a fejlesztési folyamatokat, hogy mindenki ugyanúgy csinálja a dolgokat,
kiverni az emberekből a tesztelhetőséget, stb. Ezek azok a munkák, amiktől az átlag fejlesztő sikítva menekül.
Azt ismerjük el, hogy idehaza még mindig azok vannak többen, akik arsz poétikája az, hogy "azért lettem menedzser, hogy kitapossam a beosztottaimból, amit a főnökeim tőlem elvárnak", mint akiké az, hogy "azért lettem menedzser, hogy a környezetből (ide értve a főnökeimet is) kitapossam annak feltételeit, hogy a besztottaimmal produkálni tudjam, amit a főnökeim tőlem elvárnak".
Bár személyesen az utóbbi években e téren nem panaszkodhatom (kopkopkop).
Azért ez így erős csúsztatás. Ennyi erővel azt is állíthatnánk, hogy idehaza még mindig azok vannak többen, akik arsz poétikája az, hogy "azért járok be, mert fizetést kapok", mint akiké az, hogy "azért járok be, hogy dolgozzak".
na es aki mindkettoert (vagy meg tobbert) jar be?
Diktatorok kezikonyve
Azt nem szabad, mert akkor rögtön árnyaltabb lesz a kép és így sokkal nehezebben kezelhető általános kijelentésekkel.
Ezek azok a munkák, amiktől az átlag fejlesztő sikítva menekül.
meg a dokumentalastol :-)
Diktatorok kezikonyve
+100
voltam mindkét oldalt, programozni egyszerű, akárhogy túlmagasztaljuk néha. egy leírt rendszerről van szó, amit mi alakítunk. az elmebeteg piaci viszonyok, a lehetetlen elvárások, az ezerarcú ügyfelek ehhez képest egy 1000 dimenziós játéknak tűnnek.
eddig egy programozóval volt dolgom, aki látta, hogy na srácok, ügyfél közelébe nem akarok menni, de hajlandó vagyok elfogadni hogy a sales-es 2x annyit keres mint én. nem mondom hogy így kell lennie, de azért kódolni közel se olyan háborús körülmények közti kínlódás, mint ügyfelezni, és vezetni
(megjegyzem a fenti rossz tapasztalatokat megértem, hogy miért vannak, de elfogandni nem tudom őket, csak mint sztereotípiát, ugyanis volt dolgom már jó vezetőkkel-managerekkel is, vannak akiknek én is fizettem, hogy vezessenek, mert tudtam hogy többre leszünk képesek vele)
"...de azért kódolni közel se olyan háborús körülmények közti kínlódás, mint ügyfelezni, és vezetni"
+1
deleted comment :)
Ez bizony +100
--
Gábriel Ákos
http://i-logic.hu
Szerintem aki nem programozo, az kapja be.
Az a manager, aki software-projectet visz es sosem volt programozo, az kapja be.
Az architect programozo. Pont. Meg akkor is, ha nem ir eppen kodot. Ha nem programozo, akkor kapja be. Ha tul tavol kerult a kodtol, akkor nem architect, hanem egy folosleges figura, aki altalaban nem a valos problemakra koncentral, szoval duplan kapja be. :)
eleg frusztraltnak tunsz, nem akarsz setalni egy kicsit? Aztan meg ha az a temerdek ficko egyszer tenyleg bekapja, akkor meg sirni fogsz... bar ki tudja, lehet, hogy te mar be is kaptad, es csak a viszonzas hianya miatt sirsz, LOL...
Diktatorok kezikonyve
Félig meddig ironikusnak szántam.
Nem tudom, én ügyfelekkel is foglalkozok, és programozok is. Előbbiben is vannak nehézségek, de azért ha egy alapvető pozitív hozzáállás megvan, onnantól nem egy rocket science. Persze felelősséggel jár meg minden, de azért azt gondolom hogy a csak programozók egyértelműen többet érdemelnek, mint a csak "ügyfelezők".
Lehet nem egy témakörben ténykedünk, neked az ügyfeleiddel milyen foglalkoznivaló van, milyen tevékenység mellett? Én nem csak az időpontegyeztetés-termékbemutatás-termékádatás és hasonlókról beszélek, hanem például az ügyféligények felmérésére, ...
Szóval kérlek mondd el, hogy nálad mit takar az ügyfelezés, hátha nem egyről beszélünk.
Rengeteg kis ügyfelem van (és egy nagy, de azt most inkább hagyjuk), alkalmazásbolton keresztül vesznek programot, amellyel kapcsolatban gyorsan kell megnyugtató választ adni (bug esetén < 1 nap alatt megoldást nyújtani, egyébként valamit mondani hogy mikorra várható az adott improvement/feature). Végsősoron a lényeg, hogy jól érezzék magukat. Többnyire olyanok írnak, akik már fizettek, a fegyver a kezükben az, hogy ha nem elégedettek, akkor jól lepontozhatnak.
Ez ügyféligények felmérése kategória, de valószínű hogy másról beszélünk, minden munka, minden élethelyzet más...
Ettől függetlenül fenntartom, hogy egy alkalmazás fejlesztésében a programozó a kulcsfigura. és nem a manager, vagy a sales -es. Ezt csak azért akartam kiemelni, mert látom hogy általános tendencia kezd lenni (nem konkrétan rád vonatkozik) egyszerű munkásnak (mondjuk aranybányász) tekinteni a szoftverfejlesztőket, akik révén aztán lehet kaszálni...
Ezt úgy hívják hogy bagatelizálás. Sajnos sűrű jelenség az élet sok területén a hozzá nem értőktől.
mármint melyik oldalról? hogy a manager nem csinál semmi érdemlegeset, vagy hogy a programozás szakmunka?
Menedzser oldalról értem, de a saját munkámban az ügyfelek részéről tapasztalom a leszólást és néhány kérdés fontosságának lekicsinyítését a hozzá nemértésük miatt. Ez még egy dolog lenne, sokszor a baj inkább az, hogy nem bízzák rá a hozzáértőre a kérdést, hanem saját kútfőből akarnak olyan dologban dönteni, amihez nem értenek.
(értem hogy mire gondolsz az egyszerűsítésen, azt én sem támogatom, részben ezzel kell küzdeni az ügyfelek kapcsán, ők is ugyan úgy azt hiszik, hogy "hát csak rakj oda egy gombot", csak hogy egy kis rekurziót belevigyek :) )
más tevékenységben vagyunk, te egy kész terméket, amit saját terveid alapján készítettél, ajánlasz vásárlásra, és azt support-álod, fejleszted igények szerint (ha úgy látod hogy egyezik az iránnyal amit te akarsz csinálni). én jelenleg legtöbbször ügyfél ötlete-igénye alapján fejlesztek (hozzátéve az én meglátásaim, ha elfogadják a tanácsot), itt jóval több egyeztetés, jóval több probléma kezelés van, mintha elétolnék valamit, hogy na, ezt adnám el, tetszik vagy nem, mi kéne még bele. utóbbi esetén lehet, hogy tényleg nem kell annyi management munka, ezért is próbálok elmozdulni erre felé két termékemmel
egyébként alapvetés, hogy mindenki dolgozzon, és mindenkit ismerjünk el. és mindenki csinálja azt amit szeret. egy manager azért csinálja azt amit, mert szeretné segíteni a többieket (és magát) a célja felé, azzal, hogy szervez, és optimizál, és intéz, és figyel. egy programozó meg kódolni akar, nem ügyfeleket akar látni, nem is feltétlen üzleti oldalt, csak problémákat, logikai feladványokat, szerintem. egyik sem rosszabb mint a másik, csak van két tendencia:
- egyik amiről te is írtál, a kódert szakmunkásnak nézni, mert hogy hát minden csak 2 kattintás - nem látva, hogy legtöbb esetben, ha csak kicsit is, de egyedi gondolatok kellenek, ezért ez szellemi termék előállítás, és kreatív munka, közelebb áll a design-hoz, írói tevékenységhez, mint a villanyszereléshez (nem villamos tervezést írtam, tessék figyelni)
- a másik, hogy az éremnek két oldala legyen, amikor a kóder azt mondja, hogy nélkülem semmire se menne a manager, mert nem lenne mit eladni (nem állítom hogy te ilyen vagy). ez részben igaz, de a legtöbb programozó messze nem tudna annyit (ha egyáltalán) eladni, mint amennyit akár egy középszerű sales-essel teszi. területfüggő, hogy mennyire van erre szükség, illetve sok programozó alkalmazottként szeret dolgozni, ezért ezt nem is látja (vagy akarja látni), téves adatokra építve azt mondja, hogy ááá minek ide a marketinges és a manager
Ok, ebből mindennel kb. egyet tudok érteni :)
"és kreatív munka, közelebb áll a design-hoz, írói tevékenységhez, mint a villanyszereléshez (nem villamos tervezést írtam, tessék figyelni)"
Ez mondjuk tipikusan olyan dolog,a mivel szeretik magukat a koderek onamitani: van rengeteg szabvanyos megoldas es/vagy rengeteg kesz pattern/ajanlas adott konkret problemakra. A problema viszont ezzel az, hogy:
- tul sok van beloluk
- ugyanarra a feladatra is tul sok alternativa van
- sok koder szereti azt hinni, hogy neki most muveszkednie kell alhelyett, hogy a problemat megoldana a -szituaciotol fuggoen- "szabvanyos" modon.
Ebbe sok esetben beletartozik az is, hogy egyaltalan betartjuk a hasznalt keretrendszer konvencioit...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
igazad van abban, hogy nem kell művédszkedni, de ahogy te is mondtad, van x+1 megoldás egy problémára, és általában egyik sem pont arra az esetre van, amire neked kéne, vagy kicsit változtatni kell rajta, vagy nagyon átgondolni melyik lenne a jó megoldás...
ezt fejeld meg azzal, hogy milyen szinten változnak a felhasználási szokások, a technológiák, a fejlesztési irányok, én erre értettem azt, hogy nem villanyszerelés, hogy biztosíték az biztosíték legyen. de tény, vannak már best practice-ek, és pattern-ek a megvalósításra, de még akkor is mérlegelni kell erősen, hogy mit hogy és merre alkalmazunk
Azt mernoki munkanak hivjak (es ugy is csinaljak) jobb helyen, nem muveszkedesnek.
DP, best practice-k nem kobe vesett torvenyek, hanem vaz, amire felepitheted a sajat munkad.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Mondjuk engem mindig lehangoltak azok a programozók (és munkáik), akik mérnöki munkának tekintik a munkájukat, és nem művészetnek...
A "művészkedésnek", amiről te beszélsz, van egy pejoratív felhangja, és igen, van aki azt csinálja, és az nem túl jó.
Ha viszont valaki _művészetként_ űzi, az egész mást jelent... Nem művészkedést, és nem is mérnöki munkát. Művészetet.
Hogy különbözteted meg a mérnöki munkát és a művészetet, amiről te beszélsz?
Hogy különböztetsz meg egy Gaudi által tervezett épületet egy budapesti társasháztól?
És mennyibe kerül, és mennyi idő alatt készül el? :) (Sagrada Família - 1882->2028, de ahogy a válságot meg a spanyolokat nézem, inkább 2040 a reális cél :))
Hát mint minden hasonlat, ez is sántít :P
Egy művészi szemmel felépített szoftver spórolást jelent hosszútávon, mert könnyebben karbantartható és fejleszthető kódot eredményez.
Karbantartható és fejleszthető kódnak mi köze a művészi szemmel felépített szoftverhez? Szerintem semmi. Pont, hogy a mérnöki munka (megfelelő nyelv, framework,
design patternek, standardizált fejlesztési folyamatok, stb.) által lesz lehetőségünk arra, hogy a kód karbantartható és fejleszthető legyen.
Lásd lentebb.
Azért egy Gaudi épület karbantartása rettenet nagy szívás.
Van olyan kódom, amihez fel van írva a teljes design decision tree, kiindul 3-4 user requirementből, hozzácsap még 5 technical requirementet, és fraktálisan kinyílik, 6 A4-es oldal, a végén kijön kb. 10-15 000 sornyi kód.
DE: jött persze az orosz programozó miután én leléptem, és belerondított. Nem igazán érdekelte az, hogy ez mennyire művészien van felépítve. Pedig az még logikus is volt.
Képzeld azt, hogy a kódodat, miután leléptél a cégtől, egy igénytelen értelmi fogyatékos fogja karbantartani. Tervezd meg úgy, hogy ennek ellenére jó helyre helyezze be a módosítást. Na, ez a művészet.
Igen, erről (is) beszélek. A jó kód megfelelő művészi érzékkel van megtervezve és "szimmetriákkal" bír.
Na de épp ez az, hogy a művészi érzékkel megtervezett, szimmetrikus csodakód elhasalt a karbantarthatóság követelményén
az első olcsósított jómunkásemberrel történő találkozás során.
Mit csinál egy "olcsósított jómunkásember" két vasgolyóval egy üres szobában?
...
Az egyiket elveszíti, a másikat elrontja.
Szerintem annyi az egész csel az egészben, hogy ha egy kódot X szintű programozok írtak, akkor az X szintűek kell karbantartsák. Alacsonyabb szintűek nem értik meg, a magasabb szintűek meg nem valószínű, hogy látni akarjak azt a gányolást...
Azt az X szintet már a projekt elején úgy kell kiválasztani, hogy legyen elegendő utánpótlás. Tökmindegy, hogy hova teszed a mércét, utólag már nem módosíthatsz rajta. Ha nem kapsz időben utánpótlást, akkor az a projekt halott.
Már neharagudj, de művészi munkának én azt nevezem, ahol a lényeg azon van, hogy valami egyedit, művészit alkoss.
Az, hogy megtervezel valamit, (jobb esetben ledokumentálod) majd tervszerűen megvalósítod, teszteled, üzembe helyezed, stb. az mérnöki munka.
Kevered a művészetet a kreativitással.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
+1
azert nem mindehol az n+1-edik webshopot kodoljak a programozok
--
NetBSD - Simplicity is prerequisite for reliability
Arra a fajta művészi hozzáállásra, amiről a kolléga fent beszél, nem igazán van se igény, se
szükség, sem pedig lehetőség.
Munkaadóként többre megyek egy olyan fejlesztővel, aki kevésbé zseniális, de normális, mások által követhető munkát ad ki a kezei közül, mint a művész/zseni/stb.-vel, aki bár nagyon gyorsan dolgozik, de ha bármi történik vele (otthagyja a céget, elüti a villamost, stb.), akkor ember nincs, aki megértse, hogy mit miért csinált (ugyanis a dokumentálás nem az erősségük, hiszen ott van minden fejben), és ezért az egész projekt bármikor veszélybe kerülhet.
Ez nem azt jelenti, hogy gépelő droidokra van szükség, kreativitásra igen, viszont korlátok között. A korlátok nélkül szárnyalunk kutatási témákban tökéletes, ipari termelésben nem igazán.
Nem erről beszéltem...
Írtam is, hogy egy művészien felépített kód könnyen megérthető és áttekinthető.
Az mondjuk biztos, hogy a nyelv egy korlát az információáramlás számára.
Továbbra sem értem a művészi szóhasználatot. Egy jól felépített kód,
így igen. De hogy ennek mi köze van a művészethez? Legyen rendesen,
normálisan megcsinálva, és ennyi.
Mi az, hogy művészien felépített kód?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
lehet, arra gondolt, mint a wordpress mottoja: code is poetry :-)
Diktatorok kezikonyve
Ne akard tudni.
Én értem, hogy miről beszél, csak egyfelől tényleg nem fenntartható, másfelől általában rossz irányból indítják.
Valszeg Vitruviusi, vagy Alexanderi szimmetriákról beszél. A Vitruviusi embert mindenki ismeri, az egy illusztráció ehhez. Az Alexanderi szimmetriákról képekben itt és itt lehet nézelődni.
Ezeket hogy hogy lehet kódban alkalmazni, arról Coplien írt itt.
Félreértés ne essék, lehet ilyet játszani, csak azt tessék megérteni, hogy nem lehet az EMBERT kihagyni a rendszerből. Ott bukik az egész. Márpedig itt van felhasználó és karbantartó, és úgy kell megteremteni a dolgot, hogy ezek jól érezzék magukat ezekben a terekben, különben szart se ér.
Mutatok egy szépnek vett kódot, a cikk az SVN kódjáról szól, és megtalálható az O'Reilly könyvében.
A szép kód jellemzője, hogy nem nagyon tudják összebaszni. Szerencsére az én kódomat se tudta az orosz, letört róla darabokat itt-ott, de az architektúrája - amennyire legutóbb, másfél évvel a kiadása után néztem - ugyanaz. Ez olyan mint amikor betonnal egészítették ki a Pantheont. Mondjuk rossz kódra is igaz ez sokszor...
De abban teljesen igaza van Alexandernek, hogy mindez csak akkor működik jól, ha jó irányból indítjuk: egy kódnak elsősorban a felhasználó céljainak, másodsorban a várható változások eltűrésére kell tudnia felkészülnie. Ezekre kell építeni az univerzális elveket, nem lehetnek magukban.
Ezekkel egyetértek, nincs ellentmondás.
Azt azért hozzátenném, hogy még zenét sem azért ír az ember, hohgy önmagában álljon. Különböző motivációk vannak, pl. valaki azért, hogy szívesen hallgassa, van aki azért, mert jó érzés írnia. Van aki másoknak, egy befogadó célcsoport számára akarja mutogatni, és olyan is van, aki azt akarja, hogy minél többen akarják hallgatni (akár azért mert sok pénzt akar vele keresni, akár más okból). Csak azt mondom, hogy a művészetnek általában is van céja.
persze, ha egy kozepszeru ceg, kozepszeru szoftvert akar gyartani, akkor ez a legjobb modja
--
NetBSD - Simplicity is prerequisite for reliability
Amennyire én tudom egy középszerű cég is a profitból él. Ha meg ez elérhető középszerű szoftverrel, akkor azzal fogja.
Ez triviális, kérdés ki akarja az idejét ezzel tölteni. Van, akit csak a fizetés érdekel, van aki mást is keres a munkájában...
Hat igen...
+∞
+1
mi lenne, ha az emberek olyan dolgokat csinálnának, amikkel céljuk is van? pl. ha egy programozó művészkedni akar, akkor csinálja, még a végén jó is kisülhet belőle. de persze sokan vannak, akik tudják a tutit, ezért is olyan sikeresek, és ők nem kezdenek el művészkedni. és sok érdekeset létre is hoznak, vagy nem.
az amit ma standardnak, meg patternnek hívunk, az egyszer egy művészkedő baromsága volt egy próbálkozónak. értem én, hogy ezt nem egy kkv-nál kell megcsinálni, de amúgy mit is tud csinálni egy kis cég, ha előre akar kerülni? csak csinálja ugyan azt, mint mindenki más?
Az a baj, hogy amit te művészkedésnek hívsz, azt mások mérnöki munkának. A művészet az valami olyasmi, ami valahol zseniális, de megismételhetetlen, befejezett, specializált. A design patternek ehhez képest megismételhető, adott feladathoz igazítható, általános megoldások, egyedül a zsenialitásban hasonlítanak a művészetre. A mérnöki munka nem zárja ki a kreativitást, sőt! Csak vannak korlátok, amiket nem érdemes átlépni, mert hosszú távon az csak ront a helyzeten, pl. nem kell újra feltalálni egy design patternt csak azért, mert nem tetszenek a metódusnevek.
Az építészmérnökök is csodálatos épületeket tudnak tervezni, de ők sem léphetik át a statika törvényeit, mert ha később összedől a ház, abba emberéletek kerülhetnek.
Akkor leforditom: itt arrol van szo, hogy egyesek szeretnek nagyon kulonlegesnek erezni magukat, es akkor ok most hirtelen muveszek lettek.
(Nem azok.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Csodálatos hogy sikerült elferdítani a mondandómat.
Előlről: A problémám az, hogy sokan lelketlenül végzik a munkájukat, pusztán megoldandó feladatokat látnak, nem pedig alkotnának.
Ertem, szoval ha valaki kap egy feladatot, azt lespecifikalja, tervez hozza egy megoldast, majd vetve az ajanlasok, szabvanyok, best practiclek, es patterneknek megfeleloen (amely tengerben kiigazodni mar onmagaban nem keves kreativitas kell szvsz.) elkeszit egy szoftvert, neadj'isten teszteli is, sot mi tobb, mindezt orommel teszi, akkor a tisztelt mernoki munkat vegzo ember...?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Azt én nem tudhatom. Lehet hogy művész. Ismernem kéne az illetőt, és a munkáját, általánosságban meg nem mondhatom.
Szerintem ki kellett volna derüljön (hiszen többször leírtam), hogy a problémám az. hogy sokan minden lelkesedés nélkül hidegvérrel megoldanak problémákat úgy ahogy tudnak. Az biztos, hogy más a szótárunk, de valahogy úgy tűnik, te valamiért ezt magadra vetted, pedig azt gyanítom hogy rád pont nem is igaz ez. Talán az nem tetszett, hogy a mérnök szót húztam le, valószínűleg más a szótárunk.
Mindegy, a problémám továbbra is áll, és valószínűleg veled nem van, és tényleg nem értem miről szeretnél meggyőzni.
De mondok egy példát: Itt a hupon egyszer kiakadtam X szoftverre. Erre valaki azt írta, hogy hát úgy kell rá tekinteni mint egy eszközre, a megfelelő célra ha alkalmas, tök mindegy élvezetes-e használni, meg kell oldani, csókolom. Na az ilyenekkel lehet kikergetni a világból: Könyörgöm, ha valakinek valami a munkája, akkor lelkesedjen már, ne csak a feladatot akarja letudni.
Na mindegy.
Örülök, hogy a trivialitás átment. Mission accomplished.
Ez az "a manager" elég furcsán hangzik. Egy cégnél több tucatnyi manageri ág van, pl. HR, Facility, IT, PR, pénzügyi és persze cégvezető. És ehhez jönnek az R&D közeli manageri funkciók. Pl. product manager (vagy Scrum esetén Product Owner), aki magáért a termékért felel, meghatározza, hogy mit kéne fejleszteni. (Tehát ő a vevő fele a fő kapcsolattartó. Lehet belőle több is, pl. web szerver terméknél maga a HTTP kiszolgáló, beépülő nyelvi modulok stb. felelősei.) A project manager a termék fejlesztésének menetét szervezi (hogyan, Scrum esetén ez a szerep kicsit szét van kenve).
A line manager (csoportvezetőféle) az R&D talán legizgalmasabb managere, a szervezet hosszútávú hatékony működtetésén dolgozik ezer feladatkörrel. Pl. leszervezi a munkákat a project managerrel, irányíthatja a csoport napi munkáját, az emberek karrierjét egyengetheti a cég érdekében (de ezzel rövid távon a csapata ellenében is akár), fizetést emel, felvesz, kirúg, kinevez és mindent próbál megadni a csoportnak, hogy dolgozni tudjanak kompetencia managementtől gép beszerzésen át a mindenféle adminisztrációs vackokig. Ez a sok dolog akkora teher lehet, hogy jobb esetben egy hatalommal nem rendelkező csapattagra hagyja a csoport napi működtetését, pl. Scrum esetében a Scrum Masterre. (A Scrum nem feltételezi a line management létezését, mint ahogy egy cég igazgatóét sem. Ők Scrum szempontból ún. csirkék.)
A feladatkörökből látszik, hogy nem feltétlenül a kegyetlen nagy kódereknek vagy architekteknek kell a manager pozícióra átülniük. Legfőképp nem a line manager pozícióba. És az is látszik, hogy van más, konkrét, hasznos feladata egy managernek.
subscripsi