delZubu blog

És látám az eljövendőt, hol a bűnös konzulensek örökkön szenvedtek a fenevad birodalmában. Programot kellett írniok, de jaj, milyen specifikáció alapján! Nem volt annak se eleje, se vége, az üzleti esetek helyett technikai részleteket, adatbázisműveleteket és képernyőhivatkozásokat tartalmazott. Zokogva rimánkodtak, hogy segítsek rajtuk, de én se értettem semmit belőle. A specifikációk pediglen ilyenek voltak:

"Ha a csoportvezető kattint a 'meleg szívvel segíteni' menüpontra, az alábbiakat tegyük: 1) hozzunk létre a FooMurga táblába egy olyan bejegyzést, amelynek az elemei: ID (generált, nem jelenítjük meg), FNAME (szerkesztendő, kötelező), PIPACS (értéke checkboxszal választható, a kiválasztott checkbox betűjele legyen a táblában), INEW (értéke kötelezően I, nem szerkeszthető), a többi mező üres), majd 2) szúrjuk a MEL_SZ táblába a következő három sort: A) ID generált, MSZK 8, MKEZD az aktuális dátum, B) ID generált, MSZK 12, MKEZD üres, MKREF az A) sor ID-je, C) az előzőekhez hasonló módon, egyszerűen tölthető, csak a MKEZD és a MKREF üres, MBREF az A) ID-je, a fel nem sorolt mezőket pedig abból a FROOBIE bejegyzésből vegyük, ahol FRSTART annak a hétnek a hétfőjét mutatja aminek napja az A.MKEZD. Ezeket a sorokat pirossal jelenítsük meg, és csak akkor szúrjuk be az adatbázisba, ha a FooMurga szerkesztést Commit-oltuk. Ne engedjük továbbá kiválasztani a PIPACS értékből az X-et akkor, ha van olyan FROOBIE bejegyzés, ahol a FSTAT=666 és FRSTART legalább három héttel közelebb van FREND-hez"

Ezen görcsöltek a szerencsétlen kárhozottak vég nélkül. És sóhajtoztak: "miért nem adaptáltunk agilis módszereket a projekten?" mások pedig: "ha már akkor tudtuk volna...". Verítékben úszva ébredtem.

Ami ennél is rosszabb: ez nem egy látomás volt, az aktuális munkám ilyen. A szervezők alighanem leragadtak az SSADM-nél, minden üzleti funkciót adatfolyammal és transzformációkkal írnak le, ráadásul a lehető legalacsonyabb szinten: azt dokumentálják, hogy a külső rendszerek adatbázisába milyen változtatásokat kell megtenni, illetve ott milyen megszorításoknak kell érvényben maradni. Üzleti entitásaink nincsenek is, mindenre a táblák alapján hivatkoznak, a legdurvább technikai rövidítésekkel tarkítva a "funkcionális" specifikációt. Máig nem tudom, mi a különbség a 13 és 14-es státuszkódok között, mert ezek sehol nincsenek elnevezve. Ez alapján kell fejlesztenünk.

Pedig régóta tudott, hogy a funkcionális specifikációt üzleti nyelven kell leírni. Az elvárt üzleti működést kell specifikálni, és szigorúan tilos megvalósítással foglalkozni. Ennek nagyon jó eszközei a használati esetek. Ezek algoritmusszerű leírásai annak, hogy hogyan kell a rendszerrel elvégezni, amit az ügyfél szeretne:

BUC123 – meleg szívű segítségnyújtás indítása

Előfeltétel: a felhasználó belépett a rendszerbe, és rendelkezik a szükséges (csoportvezetői) jogosultságokkal

Utófeltétel: rögzítettük az indítási kérelmet, a hozzátartozó munkafolyamatok inicializáltak és futnak

Lépések:

1. A felhasználó kiválasztja a "meleg szívvel segíteni" funkciót

2. A rendszer megjeleníti az adatok bekérésére szolgáló felületet.

Megjegyzés: A szerkeszthető mezők: Név, és a Pozitív Iterációs Pipeline Allokációs Kódhalmaz (PIPACS) kódok. Ezek közül több is kiválasztható.

3. A felhasználó megadja a szükséges adatokat, és kiválasztja a "rögzítés" funkciót

4. A rendszer ellenőrzi az adatok érvényességét, majd elmenti az új igényt

Megjegyzés: új igényhez automatikusan létrehozza a human workflow példányt (lásd TUC007 – workflow indítása)

5. A rendszer visszatér a nyitóoldalra

Azaz kb. arról szól, hogy a felhasználó akciójára a rendszer milyen lépésekkel válaszol. Sehol nem hivatkozunk implementácóra, mert nem arról szól a követelményspecifikáció hogy hogyan szeretnénk megcsinálni a rendszert, hanem arról, hogy az ügyfél hogyan szeretné használni azt. Márpedig az ügyfélnek nem az a fontos, hogy milyen táblákba mit írunk, hanem az, hogy üzletileg mit csinál a rendszer. Ugyanígy, ilyenkor még UI elemekről se írunk, az is konkrét implementáció.

Azért jó ez a megközelítés, mert így mindenki csinálhatja azt, amihez a legjobban ért. Az ügyfél alighanem keveset ért a táblaszerkezethez, viszont kiválóan meg tudja fogalmazni, hogy hogyan szeretne a programmal dolgozni. Ki tudja deríteni a hiányosságokat a specifikációban, át tudja látni a benne leírt folyamatokat, ha az ő nyelvén készült. Mi programozók meg fantasztikusan értünk ahhoz, hogy az üzleti igény alapján a legjobb implementációt adjuk. Alighanem jobb megoldást tudunk kitalálni, mint a szervező, vagy ügyfél, aki a specifikációt készítette.

Ráadásul remek eszközeink vannak arra az esetre, ha a változó igények miatt az implementációt is változtatni kell – tudunk rugalmasságot beépíteni. Már ha hagyják, hogy mi tervezzük meg a megoldást.

Vicc: "Drágám, bármikor elmondhatod vagy azt, hogy mit csináljak, vagy azt, hogy hogyan csináljam meg, de a kettőt együtt nem. Ha ugyanis azt is tudod hogy mit kell csinálni, és azt is, hogy hogyan, akkor csináld meg magad."

A mostani projekten sajna nem tudjuk a tudásunk legjavát adni. Hiába érezzük, hogy a specifikált rendszer logikáját jobban is meg tudnánk valósítani, hiába tudjuk, hogyan lehetne egy ilyen problémát szolgáltatásorientáltan, újrahasznosíthatóan, alacsonyabb költséggel megfogni, hiába van mögöttünk összesen több, mint tíz évnyi szakmai tapasztalat, mert nem az üzleti problémát mutatták meg, hanem az elképzelésüket a megvalósításról.

Mindenkinek kötelező olvasmány: Alistair Cockburn: Writing Effective Use Cases.

(warezolni is le lehet, én az ISBN kód + rapidshare –re szoktam keresni, az első lapon megvan, de ez a könyv megérdemli, hogy a polcunkon legyen. Mert talán a segítségével megmenekülhetünk a pokol karmaiból)

http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/

Ugyan már felhagytam a napilinkek postolgatásával, mert arra ott a http://del.icio.us/delzubu, ez annyira jó, hogy ide is felveszem. Hogy mik a tipikus csapdái a test-driven developmentnek, amiket jó, ha elkerülünk.

>75% -ra ismertem rá, ha csak a mostani projektet nézzük.

Bevezetőnek két egyaránt teljesen értékes állítás:

1. Ne a papírformát kövessük, mert a valós problémákat az általános módszertanok nem biztos, optimális módon oldják meg, nem tudnak a helyzetünk specialitásairól.
2. A Nagykönyvet általában nálunk okosabb emberek írták. Kapásból úgy indulni, hogy "de mi jobban tudjuk", nem kifejezetten bölcs hozzáállás, ezzel elvetjük a módszertanokban megtestesülő tapasztalatot és tudást.

Ettől aztán jó kis polémiákat lehet fakasztani, de választ nem találunk a nagy kérdésre: inkább kövessünk valami szamárvezetőt, vagy építsünk a kreativitásunkra?

A megítéléshez nekem mindig Joel cikke ad kiindulást: Big Macs vs. The Naked Chef – ebben körvonalazza, hogy a látványos sikereket zseniális hősök hozzák létre, mint amilyenek például a mesterszakácsok, csakhogy az ő tudásuk nemigen skálázódik. Ha a termelékenység növelése miatt több embert vonunk be, akkor szükségszerűen csökkenni fog a színvonal, ilyenkor a minőséget pedig csak szabályok bevezetésével tudjuk biztosítani. Amik pont azt a kreatív megközelítést pusztítják el, ami miatt a zsenik jobbak tudnak lenni, mint az átlag.

Mondjuk egy projektre vetítve mondhatjuk azt, hogy mi annyira elit csapat vagyunk, hogy szabályok helyett inkább az üzleti igényekre fókuszálunk, és a rendszer építésekor ezeket tartjuk szem előtt – agilis módszerek mentén haladunk. Vagy mondhatjuk azt, hogy a csapat, az ügyfél, vagy egyáltalán, az üzleti környezet annyira kockázatos, hogy biztosítékokat kell beépíteni a folyamatba, megyünk valami módszertan szerint. Viszont mivel az agilis megközelítésnek is van már "módszertana", pontokba, szabályokba gyűjtött tudása, a kérdés nem is az lesz, hogy úgy általában kövessünk-e módszertant, hanem hogy az adott projekten melyik mentén haladjunk.

És így feloldható az ellentét: ha a feladathoz választunk módszert, akkor nem utasítjuk el a nagykönyv bölcsességét, minden tapasztalat, antipattern és referenciaeredmény a rendelkezésünkre áll, nem leszünk egyedül. Tudjuk demonstrálni az ügyfél felé, hogy merre tartunk, milyen lesz a munkánk két hónap múlva, és tudjuk ellenőrizni, hogy tényleg ott vagyunk-e. Viszont megtartjuk a rugalmasságot, hogy pl. nem gyártunk papírhegynyi dokumentációt egy olyan munkához, ahol a követelmények úgyis hetente változnak, vagy – hogy a másik fél használhatóságát is mutassam – nem mondunk le a megfelelő teljesítési pontokról, a dokumentált munkamenetről, az adminisztrációról.

Például nemrég egy egészen MSF alapján szerveződő projekt részeként egy migrációs eszközt kellett lefejlesztenem. Aki már foglalkozott adatintegrációval, tudja, hogy az átadás utáni hónapig változni fog a követelményspecifikáció, emiatt aztán eleve nem is terveztem vízesésoid megközelítést. Csináltam valamit, leteszteltük, örültünk. Közben az ügyfél rájött, hogy mást akart. Megírtuk, leteszteltük, kijött egy bug. Javítottuk, teszteltük, stb. Valójában majdnem scrum alapokon működtünk, de ellenben elkészítettük az eszközt. Igaz, hogy nem a projekt build-ciklusa szerint mentünk, néha a dokumentáció elmaradt, és csak OneNote lapokon, vagy firkapapíron volt meg, gyakran csak informális úton kaptuk meg az új igényeket, de jó lett az eredmény, és valahol ez a lényeg, nem pedig a módszertan.

És igaz, hogy végig az igényekre fókuszáltam, és programot írtam, de azért közben örültem neki, hogy nem csak úgy megyünk bele a vakvilágba, az egyes iterációk mentén tudok haladási sebességet mérni, sőt, az igények befogadására, priorizálására, és a változások kommunikálására is kaptam mankót.

Alighanem úgy van ez a projektmódszertanokkal is különben, mint a tervezési mintákkal, és a programozási tételekkel. Tudni kell választani közülük, emiatt minél többet meg kell ismerni. Aztán ha ismerjük őket, akkor olyankor is eszünkbe fog jutni az adott helyzetben előnyös módszer, mikor egyébként nem alkalmazható. Mint mikor valaki objektum-orientált szemléletben programozik egy nem OO nyelven.

A használt módszertanoknak még egy jó mércéje, hogy hol állnak a CMMI szamárlétrán (talán már említettem, reménytelenül szerelmes vagyok mindenféle maturity model megközelítésbe). Legaluk az ad-hoc, egyéni hősiességre, áldozatkészségre épülő módszerek vannak, mikor kevés szabályunk van, inkább a csapattagok tudásán, áldozatvállalásán múlik a siker (vagy az inkompetenciájukon / demotiváltságukon / tűrőképességükön a bukás). Ahogy egyre magasabbra mászunk a CMMI szinteken, egyre több mérési és előrevetítési lehetőséget kapunk, de ennek ára van: a módszertanunk egyre formálisabb lesz. Egyre pontosabb munkadarabstátuszkövető táblázatokat kell vezetniük a fejlesztőknek programírás helyett. Egyre szigorúbb a szervezet, egyre szabottabb a döntések útvonala, egyre nehezebb csak úgy bedobni egy jó ötletet a közösbe.

Ha jól emlékszem, a The Mythical Man-month c. könyvben olvastam erről. Hogy a fejlesztők annál boldogabbak, minél nagyobb "fun" a projekt, minél szabadabbak, tehát minél alacsonyabb a CMMI szint. Ekkor motiváltak lesznek, fűti majd őket a szakmai lelkesedés, hiszen mindannyian geekek vagyunk a lelkünk legmélyén, és ezért aztán számíthatunk rá, hogy sikerre viszik a "mi" projektünket. Másrészt, ha elsősorban a követhetőségre, szabályozottságra megyünk, akkor előre megjósolható módon, de max. középszerűen fogunk teljesíteni. Alighanem kultúra kérdése, hogy ki hová állítja be az egyensúlyi pontot, egyik oldalon a sufnicégek káosza, másikon a futószalag szürkesége.

Személy szerint én alulra pozícionálok: inkább motiválok, mint behajtok. És sokat profitálok az agilisták által összehordott módszerekből még úgy is, hogy nem követem őket.

Előrebocsátom, hogy ezt a cikket az Intercityn írom, ölben tartott laptopról, úgy, hogy az előbb a kólám kihabzott, és most minden ragad. Beleértve a kezemet és a székem karfáját is. Lehet, hogy sűrűn használok majd olyan szavakat, aminek a begépeléséhez nem kell nagyon mozgatnom az alkaromat.

Ha az embereinkkel el akarjuk végeztetni a dolgukat, akkor két út áll előttünk: fenyegetőzünk, vagy motiválunk. Mivel mi vagyunk a főnökeik, ezért elvileg hathatunk rájuk azon keresztül, hogy tőlünk függ a fizetésük és vagy az állásuk, gyakorlatilag azonban így viszonylag kevéssé fognak szeretni minket, kicsi az esélye, hogy ilyenkor szívüket-lelküket beleadják a munkába. Inkább csak úgy a megkövetelt minimumot nyújtják. Ha ennél többet akarunk tőlük, akkor jó ötlet rávenni őket, hogy a saját boldogságuk érdekében csinálják azt, amit mi szeretnénk. Ezt hívom motivációnak.

Ez a totál laikus megfogalmazása a dolgoknak. Vaskos könyveket olvastam a kérdésben (jó, hosszan scrollozható PDF-eket), és a szakik valahogy sose ezt mondják. Viszont szerintem továbbra is az a dolgok lényege, hogy azt csinálják a beosztottaink, amit mi szeretnénk, de azért, mert szerintük is azt jó csinálniuk.

Ehhez ki kell találnunk, hogy mi a fontos nekik. Egyiknek a sok pénz (ők azok, akik minden túlórát bevállalnak). Másiknak a stabil munkahely (ők nem fognak konfrontálódni a főnökkel). Harmadiknak az elismerés, a dícséret (ne felejtsük le őket a hálalevelek cc-jéről). Negyediknek a hatalom (hagyjuk őket dönteni a hatáskörükben). Ötödiknek a kis privilégiumok, amiket kivívhat (ha kész péntekre, nem kell túlóráznia hétvégén). Hatodiknak a csapatba tartozás (álljunk ki mellettük, lehetőleg úgy, hogy hallják, teljesítéskor adjunk nekik projektpólót). Satöbbi, lényeg, hogy általában mindenkinek más a fontos, más miatt pörög rá a munkára.

Úgyhogy motiválni mindig egyedileg kell, és ez macerás lehet. Végül is, mikor vezetőfejlesztők lettünk, az általában azért történt meg, mert szakmailag jók vagyunk, itt pedig arról van szó, hogy az embereink lelkével kell foglalkozni. Kicsit pedagógus, kicsit pszichológusbőrbe kell bújni. Fel kell térképezni, hogy ki mire ugrik. Kávézós beszélgetéssel, ebéd közbeni hajj-mikor-még-assemblyben-nyomtuk-c64-en - nosztalgiázásokkal, kis próbamotivációk közben erősen odafigyelve, hogy melyik kollégának mitől jönnek meg a szárnyai, és mitől marad fásult, kedvetlen.

Furcsa dolog: vezetőként az egyik legfontosabb teendőnk biztosítani, hogy a beosztottaink jól érezzék magukat. Nem a munka leosztása és követése a top 1, és nem is a penge tervezés. Ez egy elég hülye felismerés, de a tapasztalataim azt mutatják, hogy ez az igazság. Ha a beosztottaink nem azt érzik, hogy ülünk a nyakukon, szívjuk a vérüket, hülye feladatokkal terheljük őket amiket más is megcsinálhatna (akár én, a főnök is, ha beszennyezném a kezemet), hanem inkább azt látják, hogy számítanak, hogy mellettük küzdünk a sikerért, legfeljebb más szinten, más eszközökkel, akkor sokkalta szívesebben vállalnak akár olyan macerákat is, mint túlóra, vagy a büdös munkadarabok.

Körülbelül ez a vezetői stílusom, egy bekezdésben körvonalazva.

És nem ragadnék le ezeknél a külső jutalmazásoknál (elég a kólába leragadni), az okosok szerint van belső motiváció is, ami arról szól, hogy a dolgozók elvégzik a munkát, mert ők maguk jól érzik magukat tőle. Akkor is, ha senki nem dícséri meg őket érte. Ha egy lakatlan szigeten vannak egyedül, még akkor is. És ez sokkal erősebb jutalmazás, mint a külső, csak hát nincs túl nagy ráhatásunk, mert mindenkinek belül van, már kialakult állapotban.

Egyik fontos belső motiváció lehet a szakmai büszkeség, hogy a programozók szeretik minőségi munkához adni a nevüket. És ez általában mindenkiben benne van valamilyen szinten, ettől működnek annyira a community projektek. Tehát ha elérjük, hogy a fejlesztést, amit csinálunk, a beosztottaink értelmesnek és jónak tartsák (ne csak egy n+1. webes keretrendszert csináljunk, ami ugyan bugos, de az ügyfélnek jó lesz), hogy a munkadarabért besöpörhessék a krediteket (tudatosítsuk széles körben, hogy a THM számoló motor XY gyereke, és a siker nagyrészt az ő munkájának eredménye), és hogy az ötleteiket lehetőség szerint ne törjük le, hanem inkább támogassuk (ha egy fejlesztőnek eszébe jut egy hasznos refactoring, akkor hagyjuk, hogy javítson a kód minőségén, ne zúzzuk le, hogy "de így is megy, inkább javíts bugokat"), akkor alighanem többet adnak majd bele a dologba, mint egyébként, ha csak a fekáliát kell lapátolniuk napi 8 órában.

Én legalábbis ilyen vagyok. És eddig azt láttam, hogy ez másoknál is mindig bejön.

Attól lehet tartani, hogy ha részfeladatokat kiadod az embereknek, akkor ők rosszabb minőségben csinálják majd, mint te, de kis belegondolás után ez az érv értelmét veszti. Akkor lenne igaz, ha a beosztottak direkt vacakot írnának, amivel csak a bajuk lesz (pedig nekik kell a bugokat foltozgatni, nem neked), vagy ha nem értenének annyira a szakterületükhöz, mint a vezető. És nem hinném, hogy így van. Bár hízelgő azt hinni, hogy mi, devleadek vagyunk a szakmai hab a tortán, alighanem a database specialista pl. jobban ért az adatbázistervezéshez, az egyszerű kóder pedig jobban ismeri a c# szintaxist, mint mi. Bízni kell az embereinkben – végül is, mi vettük fel őket a pozícióra (jó, esetleg nem pont személy szerint, de átmentek egy interjún, úgyhogy valaki alkalmasnak találta őket a posztra). Nyugodtan hagyhatjuk, hogy elvégezzék a mukájukat.

Egy veszély van csak ezzel a hozzáállással, a gold-plating. Nem véletlen, hogy az előző írásomban a minőségi tűréseket feszegettem a tányérra ragadt piszkokkal együtt. Ha valakit a minőség motivál, akkor a tökélyre törekszik, és ez így jó is. Csakhogy lehet, hogy az ő normája más, mint a projekté. Lehet, hogy a célja, a "tökéletes kód megalkotása", túl költséges lenne, és felesleges is. Intő jelek, ha valaki túl sokáig stabilizálja a kódot, nem akarja kiengedni a kezéből. Vagy a kész munkadarabot azonnal "refaktorálná", mert nem elég szép. Vagy ha "általános megoldást" akar csinálni akkor is, ha ez nem igény. Ilyenkor nagyon óvatosan, de határozottan le kell őket beszélni erről.

Ami azért ciki, mert a fentiekben pont az ilyen ötletekre írtam, hogy motiváló erő. Pont hogy ne törjük le a kezdeményezést. Ettől kell ilyenkor különös diplomáciai érzékkel hozzáállni a problémákhoz. Például nagyon jó helye van az efféle teendőknek a backlogon, "csináljuk egyszer meg, mert szerintem is fontos, csak ne most azonnal, mert magasabb prioritású feladatok is vannak számodra". Vállaljuk magunkra, hogy kezeljük ezeket, és ha van idő, csinálhatja. Vagy csinálhatja őket a szabadidejében, hobbiból, másik branchen, de a heti célkitűzésbe nem vesszük be. Nálunk csomó idő van a projekten, amikor pihennek a fejlesztők – build alatt, amíg a tesztek futnak, addig foglalkozat a hobbi feladatokkal.

Eddig a legerősebb demotiváló kijelentés, amit hallottam: "ez nem szakkör. nem élvezetből programozunk". Ne használjuk!

Konklúzióként kiegészíteném a fenti ars poeticámat: vezetőként a másik legfonotsabb teendőnk biztosítani, hogy a beosztottaink elvégezhessék a munkát, ami a céljuk. És persze, el kell érnünk, hogy a céljaik fedjék a mienket. De körülbelül ennyire van szükség, a többi csak hab a tortán, vagy a választott módszertan által ránk erőltetett nyűg.

Ezekről meg majd máskor írok.

ps.: motivációról szóló cikk nem lehet teljes a flow megemlítése nélkül. Ennek most eleget tettem, de nem hiszek benne annyira, mint mások, úgyhogy akit érdekel, olvassa el a wikipédián.

Otthon általában párom főz, én mosogatok – még mindig sokkal jobb, mintha azt kéne megennünk, amit én főzök, de ettől még nem szeretek mosogatni. Ezért néha előfordul, hogy a rendkívül alapos házimunkám ellenére koszos marad egy tányér, vagy kés. Tegnap is talált ilyet a párom, és én jó konzulenshez méltó módon elmagyaráztam neki a csökkenő hozadék elvét:

Ha egy folyamatban valami értéket növelni akarunk, akkor minél nagyobb a kiindulási érték, annál költségesebb lesz az egységnyi növekedés. Tehát például ha van egy autónk, ami maximum 80-nal tud menni, akkor nagyon olcsón el tudjuk érni, hogy képes legyen a 100-zas végsebességre, míg pl. 300-ról 320-ra emelni egy kisebb vagyon. Ennek megfelelően tehát érdemes a tökéletesség felé vezető úton csak addig haladni, amíg a következő lépés költsége kisebb, mint a várható haszon.

Azaz elmosogathatok mindent 100% higiénikus tisztaságúra, de rendkívül fogom utálni, tehát ritkán csinálom majd. Jobb, ha becsúszik néha egy-egy koszos kés, azt visszadobjuk, de összességében nem kell annyi energiát fordítani a dologra, mintha mindent hatszor öblítenék.

És hogy hogy kapcsolódik ez az informatikához? Hogy a mi szakmánkban is nagyon sokszor a "tökély" a cél: legyen minden lespecifikálva mielőtt elkezdjük a tervezést, legyen minden megtervezve, mielőtt programozni kezdünk. Legyen minden kód optimalizálva, refaktorálva, legyen a coverage 100%, legyenek a hibák egytől egyig kijavítva átadás előtt. És gyakran valami túlvilági ideák lebegnek a szemünk előtt ezekkel kapcsolatban, pedig a fenti elvnek kéne.

Hogy elképzelhető, hogy a coverage csak 70%, de 80%-ra emelni költségesebb lenne, mint ami hasznot egy így megtalált hiba jelent. Hogy a specifikáció még nem stabil, változni fog, de ölbe tett kézzel várni a szervezőkre drágább, mint elkezdeni a munkát a félkész speckó alapján, majd átírni, ha véglegesül a követelményhalmaz. Hogy a brute-force megközelítés alighanem már rég megadta az eredményt, mire a szofisztikált megoldást egyáltalán kitalálnánk.

Természetesen minden projekten más az a minőségi cél, amit megfelelőnek tartunk – egyáltalán nem mindegy, hogy egy belvárosi bevásárlóautó, vagy egy forma1-es versenyautó sebességét akarjuk beállítani, ez utóbbi esetben nyilván sokkal többet megér az a +20km/h. Ugyanígy, ha egy milliók által használt programot készítünk, akkor kevesebb ismert hibát fogunk benne hagyni, mint mikor egy egyedi megoldást szállítunk, és marha egyszerű garanciális javításokat adni. Ha kernelmódban futó grafikus modult írunk, azt nyilván jobban optimalizáljuk, mint mikor egy egyszer lefutó migrációs scriptet készítünk, stb.

Azaz nem mindegy, hogy otthon mosogatok, vagy egy ötcsillagosban.