Apály

A nagy vállalatok szoftverfejlesztési gyakorlatában az az egyik legnagyobb kihívás, hogy nem a feladat komplexítása, hanem az üzleti priorítása határozza meg a költségkeretet. Ennek következtében még akkor is, ha egyébként a feladat egyszerű lenne, a kelleténél több szoftverfejlesztőt és egyéb munkatársat kap, mindenki hozzáteszi a saját elképzeléseit és mivel a keretet ki kell tölteni, a keletkezett megoldás hozzáadott komplexítása rendesen megnő.
Idáig minden rendben is lenne, de az üzleti priorítások változnak. Amikor végre valami "kész", új dolgokat kell építeni és nem várhatja senki a cégtől, hogy örökké top listán tartsa a projektet. Itt kezdődnek a problémák, mert innentől kezdve a csapat évekig vonszolja maga után a keletkezett komplexítást. A befektetett összegért a cég produktivítást várhatna, de hát mit csináljunk ha pont az ellenkezőjére fordítottuk?


Nos a leggyakoribb megoldás az, hogy a csapatot is lecserélik, ettől lesz mégrosszabb.
Illetve egy okosabb cég egy idő után arra a következtetésre juthat, hogy ez nekik nem megy valami jól és ideje inkáb beszálítókkal és dobozos termékekkel kielégíteni a szükségleteiket. Sok szerencsét hozzá :-D


Kevésbé okos cégek esetében: örökké ismétlődő Halálcsillag Design Pattern.

Illetve elvben létezhet olyan, hogy valaki nem megy bele ebbe az egész csapdába, csak még nem láttam ilyet.

Outsourcing magyarázat - ötlet

Szóval van ez az outsourcing dolog: Évekig dolgozunk a vevőnél, a munkáltató céget akkor látjuk utoljára, amikor a szerződést aláírjuk, a pénz jelentős százalékát leveszik és kirúgnak ha a vevőnek nincs rád szüksége. A vevőnek nyilván így kétszer-háromszor annyiba kerülsz, mintha alkalmaznának, a te fizud meg nagyjából ugyanannyi. Magyarországon ehhez még olyan sajátosságok is jöttek, hogy konkrétan az outsourcing cég hónapokig lógott a fizuval, pedig a vevő elégedett volt és időben fizetett, de a górénak új kocsit kellett venni.
Nem hangzik olyan jól, igaz?

Azokban akik ezt csinálják évekig, nyilván felmerül a kérdés, hogy ennek ugyan mi értelme van, miért megy bele még így is a vevő? Gondolom nem hülyék, nem gyerekesen gonoszak, illetve a kapzsiságnak is fursa módja lenne hogy többet fizetsz ugyanannyi munkáért. Logikus magyarázat kell...

Na és erre van egy friss összeeskövés elméletem, ezt szeretném megosztani veletek, tessék:

Amikor az emberek még alkalmazottak voltak, egy csomó idő ment el arra, hogy a pozíciójukat védték a munka helyett, karriert építettek szoftver helyett, meg persze marakodtak.
Most nincs se karrierünk, se pozíciónk, meg igazából le is vagyunk szarva. 3-6 hónapra vesznek fel, szóval mindenképpen elveszítjük a projektet. Egyszerűen túl drágák vagyunk ahhoz, hogy így bármelyik projekt meg akarjon tartani minket hosszabb távon. Viszont annyi különbséget tudunk tenni, hogy sikeresen vagy sikertelenül veszítjük el a projektet. Ha sikeresen veszítjük el, az ügyfél nagyon köszöni, jó eséllyel lesz másik munka. Ha sikertelenül veszítjük el, elcsesszük a határidőt vagy a vevő elhúzza a száját, akkor az valószinűleg az utolsó volt. Max 6 hónapod van, csinálj csodát!
Tehát hajrázunk örökké. Nincs baszakodás, nincs okoskodás, nincs állóháború, megy a meló.

Ennyi lenne.


A hátulütő persze nyilvánvaló, az átadásnál elveszik az infók nagy része is, de hát akinek nem kell ezzel közvetlenül foglalkoznia, annak ez nem hiszem hogy álmatlan éjszakákat okozna.

Azért ez szerintem jelentős különbség. Lehet, hogy megéri. Nagy cég, ufó-logika. 

optimalizáció

Gyakran zárnak rövidre egy-egy vitát szoftverfejlesztésben azzal a rövid kifejezéssel, hogy "premature optimization" vagy "early optimization". A probléma az, hogy kicsit elcsépeltük ezt a kifejezést. Bármikor bárki teljesítménnyel kapcsolatos kifogást mer megfogalmazni, szinte biztos, hogy valaki a fejéhez vágja. Nem azt mondom, hogy bitek, hálózati csomagok, vagy megszakítások szintjén el kellene kezdeni kitaposni több sz-t a számítógépekből, hanem:

1. Legyen a fejlesztőknek képe arról, hogy milyen teljesítményt vár el felhasználó / megrendelő a rendszertől
   És persze a megrendelő legyen udvarisasan tájékoztatva arról, ha irreálisak az elvárásai
2. Legyen legalább az architektnek és a vezető fejlesztőknek elképzelése arról, hogy az az architektúra, amit megterveztek a sok kis nyomorult kockával az Enterspájz Architekt-ben, az hogyan lehet képes ezt a teljesítményt biztosítani némi biztonsági tartalékkal.
3. Legyen a rutin tesztelés része az, hogy nagy terhelés alatt is korrekt eredményeket gyártson a szoftver.

Ezeket azért írtam össze, mert olyan ritkán láttam a gyakorlatban, együt pedig még soha.

A problémák, amiket én tapasztaltam:

1. Általában fogalmunk nincs a komponenseink teljesítményigényéről. Nem tudjuk mennyi idő, amíg az adatbázis válaszol, vagy a hálózaton átverekszi magát egy IP csomag, vagy hogy egy JSON dokumentumot parsoljunk. Csak annyit tudunk, hogy marha gyors. Mire pislogtam kész volt. Mire ezret pislognék biztos az éles rendszeren is lefutna.
2. A technology hype kifejezetten nem tesz jót, az emberek hajlamosak azt hinnni, hogy a legújabb/legdrágább technológia tényleg jobban muzsikál, mérés nélkül. Ilyenkor egy faszpörgettyű, aki lefikázza a drága / awesome rendszert egy pár órás teszt alapján, kifejezetten idegesítő tud lenni.
   Például egy régi főnököm mondta ezt a nyafogásomra: "Az Oracle végtelenül skálázható" - jó persze 2000-ben még sokan ezt hitték
3. Van egy kifejezetten kedvezőtlen légkör jól pénzelt/priorításos projektek körül, valahogy az emberek összekeverik azt, hogy a "szoftver jól teljesít" azzal, hogy "a szoftvernek nagyon jó teljesítményű hardverre van szüksége... és sokra persze".

Megoldás: a természetes szelekció elvben ki kell hogy küszöbölje a problémát még mielött a Tejút ütközik az Androméda köddel.