Szerintem pedig az az ok, hogy "hígul" a szoftverfejlesztői szakma, és egyre kisebb és bizonytalanabb tudású emberek készítik a szoftvereket, amik meg egyre nagyobbak. Néha olyan megoldásokkal találkozom, hogy elgondolkodom rajta, hogy miért is nem mentem inkább halásznak. Igaz, hogy a halászok korán kelnek, büdösek, de nincsenek ilyen problémáik, hogy pl. javíts bugot egy olyan szoftverben, amiben a változókat és az osztályokat nem aszerint nevezték el, amire használják őket, a terminológia nyomokban sem emlékeztet az üzleti terminológiára, és ha bővíteni kellett valamit, akkor nem plusz egy oszlop a megfelelő táblába, hanem plusz 3 tábla összejoinolva orrba szájba ID1, ID2, ID3 oszlop nevekkel, rendszerterv persze sosem volt, a felhasználó meg folyton panaszkodik, hogy lassú a szoftver (tényleg lassú), mert 20 millió soros táblákból joinol össze 5-öt (!), hogy megszerezzen olyan adatokat, amikből 10x annyi van táblánként, mint amennyi a tényleges adat lenne 1 táblában.
Na ezért lassú. Mert a profit az első, programozóból meg jó lesz az egyetemista is, tesztelni meg ugye minek, majd a júzer, QA hallomásból sem, elbírja ez, elbírja.
Mert például nálunk a felsőoktatásban is (Óbudai egyetem) az a fontos, hogy szoftver szigorlatra ismerj 15 féle rendező algoritmust, meg fejből tudd a b-tree kezelő algoritmusokat, de csak olyan megoldást fogadnak el, amit a tanár leadott órán, ha más (pszeudo)kódot írsz a vizsgán, lepontoznak, hiába jó a tied, a tanáré meg szar. B*meg, mi a búbánatnak kell 15 féle rendező algoritmust tudni??? Sokkal fontosabb lenne megtanítani a palántákat GONDOLKODNI, nem bemagoltatni velük a sok használhatatlan nyavaját, illetve egy szoftverfejlesztőnek tudnia kellene rendszerben gondolkodnia, képes legyen a problémát (feladatot) emésztető méretűre felbontani és tisztességesen megoldani. Amíg a modul fan in/fan out minimalizálás csak a szoftvertechnológia vizsga egyik kérdésében merül fel (lexikális tudásként), de soha többet sehol sem említik (a gyakorlati tárgyakon sem), addig nagy baj van.
Nagyon kevés jó fejlesztővel találkozom. Manapság a szoftvergyártás futószalagos tömegtermelés lett, olcsóbb, de persze sokkal szarabb minőségű is.
Assembly-ben is lehet lassú szoftvert írni, csak aki neki mer állni assemblyben megoldani egy komolyabb problémát, az valószínűleg már nem a szakma alján van. Volt szerencsém olyanhoz is, hogy "perl mágusok" kitalálták, hogy majd ők hiperszuper Java fejlesztők lesznek. Nem lettek. Nem azért, mert perl-ben nem tudtak megírni akármilyen text file manipuláló cuccot, vagy ne lettek volna képesek akármilyen algoritmust megírni Java-ban. Még a polimorfizmust is majdnem megtanulták. Hanem azért, mert aki perl scripteken szocializálódik, és el van telve önnön tudásával, a bödös életben nem lesz képes egy nagyságrendekkel bonyolultabb, 3 rétegű alkalmazást hatékonyra, könnyen tesztelhetőre és könnyen módosíthatóra megírni, semennyi pénzért sem.
Bocs a kirohanásért, csak mostanában gyakran futok bele olyanba, hogy mikor már az összeomlás szélén áll a projekt, kell valaki, aki kirángatja őket a szarból, persze akik okozták az egészet, nem ismerik be; ha már leléptek felmarkorva a zsíros pénzt, akkor az ügyfél lesz már rohadt ideges, hogy mivanmár és miért fog még ennyibe kerülni, hiszen egyszer már kifizette; ha meg még ott van még a szarkavaró brigád, akkor a gatyábarázás után meg hirtelen már nem kellünk, és nem hogy "köszönöm szépen, hogy segítettél megmenteni a munkám" hanem "büdösek vagyok, és különben is miattatok van minden" módon kiutál, mert a StyleCop full fasiszta beállítását nem vagyok hajlandó tolerálni, de hát valamibe bele kell kötni, mert a kódomat nem érti a drága.
Na ezért lassú.
A sok gyökér miatt.