- 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 - 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.
- 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:
- Á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.
- 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 - 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.
