> Magyarul érdemes lenne akkor váltani, amikor érdemes váltani, nem rögtön az elején?
Az a baj, hogy ha elindul a lavina, akkor nincs megállás: ha egyszer már megcsinálták excelben, akkor a cégvezetés ragaszkodni fog hozzá, hogy de kattintgassák benne össze a következő fejlesztést is. Erről szólt a sztori is.
> Ez egy csodálatos oximoron, ellent mondassz önmagadnak. Az általános szabályokból álló, könnyen fejleszthető cucc az pont hogy svájci bicska.
Egy nagy túrót. Az excelt magát te nem fejlesztheted, az maga a munkaeszköz, nem a célszoftver, ezért az a svájci bicska. Az általános szabályokból álló, könnyen fejleszthető cucc, az a rendszerezett alkatrészbázis, amiből építkezhetsz és bármit megépíthetsz.
> Sajnos érvként csak az hangzik el, hogy az egyik rendes szoftver, a másik meg csak az excel.
Egy raklap érv elhangzott már, de azokat menetrendszerűen lesöpröd az asztalról...
> Ha rosszmájú lennék, akkor elintézném annyival, hogy szarul szokták specifikálni. De nem vagyok, úgyhogy inkább kifejtem: Tulajdonképpen igen, ezt feltételezem, de azért mert ez a reális, több okból is. Ugye kb két út van, 1) leveszünk (és a szükséges mértékben testreszabunk) egy kész terméket. 2) Fejlesztetünk magunknak egyedit.
>
> Az egyes esetén a specifikáció környékén a cég nem volt képben, maximum valami feltételezés hasonló cégek igényeiről (általában vetekedve más típusú cégek igényeivel).
Erre csak azt tudom mondani, hogy nem reprezentatívak a tapasztalataid, nem minden fejlesztőcég inkompetens.
> - Itt pont annyi esély van jól specifikálni, mint a microsoftnak.
Ez nem igaz. Ez egy borzasztó nagy csúsztatás; aki belelát az nagy valószínűséggel tud adni egy adekvát specifikációt.
> - Vagy nagyon széles felhasználásúra lőjük be, és akkor magától is svájci bicska lesz, ahol pont ugyanannyira lehet inkompetensen gányolni, mint excelben.
A bővíthetőségnek kell szélesnek lennie, nem a felhasználásnak. (Lehet az is, de a bővíthetőség a lényeg.) És a "lehet" az nem érv. Lehet, hogy lehet egy ilyen rendszerben is "inkompetensen gányolni", de az excelben ez sokkal valószínűbb, mert az nem is erre való.
> - Vagy szűkebbre, és akkor potenciálisan beveri a fejét az ember, aztán lehet hozzányúlni, vagy hozzáigazítani a céget (lásd a klasszikus SAPs viccet, hogy "- de hát a mi cégünk nem így működik." "- még"
Ezért kell a bővíthetőséget úgy megoldani, hogy ne gány legyen.
> - Amikor hozzá kell nyúlni, annak meg több köze van az excelben gányoláshoz, mint a rendes szoftver fejlesztéshez. Általában integrátor cég csinálja, aki ugyan ismeri az eszközt, de nincs direkt ráhatása, az esetlegesen coreban előjövő bugokat vagy megpatkolja, aztán lesz valami, vagy viszonylag lassan keresztülveri a gyártón, nem fér hozzá pl a komplett unit és integrációs teszt készlethez, és általában véve integrációs projektként kalapálja bele a dolgokat a keretekbe. Ez csak akkor jobb az exceles alternatívánál, ha feltételezed, hogy aki az excelt csinálja, az hülyébb.
Csak ismételni tudom magam: a tapasztalataid nem reprezentatívak. Ez amit leírtál, ez egy elbaszott fejlesztési protokoll, hogy kiszervezik valami balfasznak, aki összebasz valami szart; hát úgy tényleg nem sok előnye lesz egy túlokosított exceltáblához képest. :/
> A kettes esetben meg specifikálni csak a jelen állapotban lehet. Ilyet egy cég azért csinál, hogy a konkrét gondjait megoldja, arra senki nem fog pénzt áldozni, hogy egy általános keretrendszert fejlesztessen, hátha alapon. (Olyat ugyanis le tud venni a polcról az egyes pont alól még most, nem majd két év múlva). És akkor most vegyük a példádat: a sztori elején a cég maximum annak a contact kezelő rendszernek az igényeit tudta volna rendesen átadni, arról ugyanis, hogy mondjuk három év múlva mire lesz szüksége fogalma sincs. Valami elképzelése ugyan lehet, aminek a valósággal majd lesz talán némi metszete (talán eltalálják, hogy mivel fognak foglalkozni három év múlva, és hol lesz a fókusz, de az akkori processz igényeik részleteirő még fogalmuk se lesz).
Hát ebben már inkább van valami, de épp itt jön képbe az, hogy valami könnyen bővíthető rendszerre kell alapozni és akkor később nem lesz gond.
> Szóval ha itt megpróbálunk specifikálni, akkor az a specifikáció szar lesz. Nem azért, mert a rendes szoftver fejlesztők inkompetensek, hanem azért, mert esélyük sincs.
Ez kb. a "megrendelő azt se tudja mit akar" esete, ott tényleg nem túl egyszerű íkúból specifikálni...de lehet tapasztalatból helyette. Miféle a cég? Mit csinál? Hogy működik? 99.999999999999999...% az esélye, hogy nem egy teljesen egyedi infrastruktúrával és célokkal bíró cégről beszélünk, tehát a hasonszőrü cégeknél összeszedett tapasztalatokból össze lehet szedni azért azt a specifikációt; és ugye még mindig ott van, hogy ha a rendszer könnyen bővíthető, akkor nem akkora baj, hogy valami kimaradt belőle, mert arra senki nem gondolt.
> Itt kénytelen vagyok nyitni egy másik szálat, és elveimmel ellentétben microsoft termékeket fogok védeni, mert látszik, hogy neked az excel meg a "fejlesztés" legalább annyira fáj, mint nekem a "csodaszoftver". Ugyan én magam is ott szoktam az ilyesmit elengedni, ahol hozzá kéne nyúlni egy makróhoz, de azért javasolnám megtekinteni azt az office suitot fejlesztő szemmel egyszer alaposabban. Rég elmúlt már az az idő, amikor valami förmedvény visual basic volt benne és csá. .NET van alatta, normális komponensekkel kb mindenhez, használható editorral (bár igen csodálkoznék, ha visual studioból ne lehetne hozzányúlni) erős a gyanúm, hogy ha valaki rendesen áll neki benne fejleszteni, akkor semmivel nem lesz az rosszabb, mint akármi más, és igazából a cészoftver cégek nagy szerencséje, hogy elterjedt az agyakban, hogy az szar, és csak gányolni lehet benne.
Itt most megint állítottál valamit rólam, ami nem igaz, másfelől meg olyan érveket hozol fel az excelben való fejlesztésre, amik teljesen irrelevánsak. Tök mindegy, miben lehet benne megírni a makróidat: egy táblázatkezelő makrói nem egy ügyviteli rendszerre lettek kitalálva. Mellesleg a VBS semmivel nem volt rosszabb, mint a JS, vagy valamelyik másik rettenetes szkriptnyelv, a .NET viszont egy eléggé bloated keretrendszer.
Egyébként amit leírtál az egy tipikus szoftverbetegség: a túlokosítás és az egybeintegráltság. Ami mindenre jó, az nem jó semmire. Azt kell tudnia, amit tudnia kell és nem háromezer másik mindent. De ezt már a múltkor a systemd kapcsán sem értetted...
> Egyrészt, rengeteg mindent valóban good enough meg lehet csinálni gyorsan.
Persze, appróbb feladatokra tuti, de itt nem ez volt az elvárt.
> Másrészt nem csodálkoznak rajta, hanem le se szarják, a cél ugyanis nem bugmentes szoftver, hanem a működő üzletmenet, és a money-money-money.
Tehát neked nem baj, ha úgy szar ahogy van, amíg dől a lóvé?
> Hát miért nem csinálják jól? Végül is ezek a cégek abból élnek, hogy rendes célszoftvereket gyártanak, nem? :)
Rengeteg az inkompetens programozó. Megnőtt az igény és a képzési rendszer képtelen volt kielégíteni a keresletet. Onnan toboroznak, ahonnan tudnak. (Nem mintha egy egyetemi diploma garancia lenne arra, hogy valaki ért hozzá.) Olyat kell keresni, aki tényleg ért hozzá. Nem csak az igényeket kell felmérni, a kivitelezőt is. (De egyébként házon belül is meg lehet oldani, ha van kompetens fejlesztő a cégnél.)
> Szóval akkor az van, hogy igazából nem az excellel volt a baj, hiszen az le volt dokumentálva rendesen, hanem azzal, hogy tróger meló. Azért tróger meló, mert excel. Nem érzel itt némi elitizmust? :)
Nem. Nem azért tróger meló, mert excel, hanem azért tróger meló, mert egy olyan excelben konstruált rendszert kellene túrni, amit nem excelben kellett volna megkonstruálni. Ebben semmi elitizmus nincs, ezt megint te magyaráztad bele.
> Bocsánat, de ez ki fog hallatszani. HAHAHAHAHAHAHAHAHA. Édes istenem, hát más sincs ilyenkor, csak az, hogy "újra kell írni az egészet", "fogalmunk sincs meddig fog tartani", "először 1 hónapig csak teszteket írunk (ebből persze minimum három lesz), addig hozzá se merünk nyúlni, mert fogalmunk sincs mi fog elbaszódni", "én ehhez hozzá nem nyúlok", "nem értem", "ez egy legacy szar".
Isoraz: nem reprezentatívak a tapasztalataid.
> Egyrészt igen, de ez még mindig nem jelenti azt, hogy a legyen már egy rendes telefonkönyv automatikusan kellett volna a "most azonnal vezessünk be egy vállalatirányítási rendszerthez" vezessen
Nem jelenti, de a kettő nem is következik egymásból. Ha tényleg a telefonkönyv csak az igény, akkor oké, de ha nem...? Azért ennyi kompetenciát a vezetőségtől is el lehetne várni.
> Fentebb már bővebben kifejtettem, de kérlek, a kis anekdota esetén hogy mérted volna fel?
Ezt meg én fejtettem ki bővebben fentebb: a céget be lehet sorolni működés, célok és struktúra alapján, ezek alapján pedig kb. kiókumlálhatóak az igények.
> Ja, és olyan, hogy tuti nem fog nőni, egyszerűen nincs.
De van olyan, hogy nem fog nőni. Számtalan példát láttam már, hogy valami apró szöszmösz cuccra ugyanazt az exceltáblát használták évekig. (Listákra, meg hasonlókra.)
> Jajj, de tudtam, hogy nem kéne hülye példákat hozni. Egy cég nem egy ország.
Te hoztad a cég/ország analógiát, az ágyús példával. :]
> Ez nem válasz. Ha mindig mindenre előre kell gondolkodni, és túltervezni, az nem megy. Nem lesz ugyanis miből.
Ez a nem válasz. A gondolkodás még nem kerül pénzbe.
> És el is érkeztünk a lényeghez, szinte az egész fönti eszmefuttatás elhanyagolható ehhez képest. "Profitcentrikus". Mégis, szerinted mi egy cég célja? Eltaláltad, az hogy profitot termeljen. Nem az, hogy az alkalmazottaknak kényelmes legyen. Még csak nem is az, hogy a cég a világ végéig működjön. Azok a döntések, amik nem ebbe az irányba mutatnak, rossz döntések.
Rossz szó volt a "profitcentrikus". Inkább a "profithajhász" lenne a jó.
Igen, egy cég célja a profit termelése. De nagyon nem mindegy, hogy hogyan termeli.
> Nem állunk neki minden piszlicsáré problémát túlfújni, és most azonnal előre gondolkodva öt évre megoldani. Ahhoz ugyanis kb minden cég azzal kellene kezdje az életét, hogy kb egy racknyi vasat, egy csomó drága szoftvert, meg legalább egy teamnyi ITst beszerez. És akkor ez még csak az IT volt.
Ez eléggé nagy csúsztatás. Lehet lépésben fejlődni. Pont a szervercluster-építést nagyon jól lehet lépésenként csinálni. A kész szoftvereket is be lehet szerezni akkor, amikor épp szükség lesz rájuk. Ennek semmi köze ahhoz, hogy nem megfelelő eszközben fejlesztik le a saját céges rendszerüket, amivel magukat fingatják meg.
> Ehelyett inkább termelünk profitot, és majd ha három év múlva már nem elég az excel, mert láthatólag akadályoz a munkában (ha jó a cégvezető, akkor akkor, amikor már látszik, hogy akadályozni fog), akkor megnézzük, hogy mivel lehet megoldani.
És ilyenkor jön az, hogy kell a lóvé a cégvezető új yachtjára, BMW-jére, meg luxuskurvájára, úgyhogy basszátok össze excelben, leszarom, csak menjen.
> Három évnyi előnyt adva az ITnek, hogy ne egy három éves technikát kelljen használni, hanem azt, ami akkor a legjobb.
Hogy micsoda? Egy szoftver nem attól lesz jobb, vagy rosszabb, hogy újabb vagy régibb!
> Három évnyi profittal a zsebünkben, amit nem költöttünk el olyanra, ami addig nem kellett.
És akkor még mindig tudjuk azt mondani, hogy ez már felesleges, mert nem éri meg beletenni a megkeresett pénzt, nem fog megtérülni, és lehet vele mást is csinálni. :)
Pontosan erről beszéltem; akkor sem fogják már rendesen megcsinálni a rendszert, pont mint az exceles sztoriban, mert "nem éri meg" olcsóbb összehányni excelben. És pontosan ezt fogalmazta meg Ebcsont is az "olcsójánosságos" posztjában.
Körbe-körbe futunk, sose fogunk dűlőre jutni. Főleg a profitról alkotott nézeteink különbsége miatt; nekem elfogadhatatlan, ha valakinek úgy van kurwa nagy profitja, hogy mindent leszar, mindent szarul csinál, csak dőljön a lóvé még máma; ez olyan amcsi multis üzletpolitika. Exploit the today, ignore the tomorrow.