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