Abstrakty vybraných príncípov softvérového inžinierstva (1-152)

Keď nie je softvér efektívny, je obyčajne možné izolovať časť programu, ktorá konzumuje väčšinu strojového času počítača a predizajnovať alebo prepísať ju na zvýšenie efektívnosti (princíp 194). Zlá spoľahlivosť nie je len zložitejšia na detekciu ale je aj náročnejšia na odstránenie. Nespoľahlivosť systému sa nemusí stať zrejmou až do obdobia keď sa systém rozvinie a sám zničí. Keď sa nespoľahlivosť zviditeľní často je zložité zistiť jej príčinu.

Najjednoduchší a najefektívnejší spôsob zníženia nákladov na vývoj softvéru a s tým spojeného rizika je nákup hotového produktu namiesto vývoja od nuly. Je síce pravda, že hotové produkty dostupné na trhu môžu riešiť len 75 % vašich problémov, ale môže nastať aj takýto prípad: Zaplatíte najmenej desaťkrát toľko, vezmete na seba riziko prekročenia rozpočtu o 100 % a nesplnenia termínu dokončenia (ak sa vôbec dokončí) a keď bude všetko hotové, zistíte, že tento produkt spĺňa opäť len 75 % vašich požiadaviek.

Pre spotrebiteľa vyzerá každý nový softvérový projekt vzrušujúco a zaujímavo. Vývojový tím je optimistický a plný viery v dokonalé konečné riešenie. Ale len málo softérových projektov prebieha hladko. Postupné zvyšovanie nákladov má obvykle za následok redukciu požiadaviek kladených na vyvíjaný produkt, následkom čoho je jeho výsledná úžitková hodnota taká, ako u porovnteľných hotových produktov. Ak ste softérový vývojár, mali by ste využívať znovupoužiteľnosť v maximálnej možnej miere. Znovupoužiteľnosť je v podstate "nákup namiesto vývoja".

Softvérové nástroje (ako napr. CASE) zvyšujú efektívnosť ich užívateľov. V každom prípade ich používajte. Práve tak ako textový procesor je základnou podporou spisovateľovi, CASE nástroje sú základnou podporou softvérovému inžinierovi. Každý nástroj zlepšuje používateľovu počiatočnú produktivitu o 10 - 20 %. Každý nástroj znásobuje používateľovu schopnosť meniť a vyvýjať svoj softvérový produkt o 25 - 50 %, ale v žiadnom prípade nie je samostná práca - myslenie urobená daným nástrojom. Používajte CASE ale budte realistickí pri zvažovaní jeho vplyvu na produktivitu. Majte sa na pozore, pretože 70 % zo všetkých zaobstaraných CASE prostriedkov sa nikdy nevyužije. Verím tomu, že základnou príčinou spomenutého problému je nadmerný optimizmus a následné sklamanie ako neefektívnosť použitých nástrojov.

Pracovné sanice s podporu CASE prostriedkov stoja $5000 - $15000. Cena za samoné CASE prostriedky sa pohybuje od $500 do $50 000. Poplatky za každoročnú údržbu a obnovy licencie CASE prosriedkov predstavujú 10 – 15% samotnej ceny, ku ktorej treba samozrejme eše prirátať platoy na 2 až 3 dni pre každého vývojára na výučbu. Teda, celkové porebné náklady na vybavenie jednej pracovnej stanice sa môžu vyšplhať na $17 000 (pre strednú cenovú kategóriu CASE prostriedkov) a náklady na každoročnú údržbu môžu dosiahnuť $3 000.

CASE prostridky sú nevyhnutne potrebné pre vývoj softvéru. Ich cena sa následne odráža v cene následne vyvíjaného softvéru. Pri spätnej analýze výdavkovtreba brať do úvahu najvyššiu cenu pre zakúpenie CASE prostriedkov, ale takisto musíme prihliadať aj na náklady spôsobnené ich nezakúpením (nižšia produktivita, väčšie problémy spôsobené nespokojnosťou zákazníkov, oneskorené ukončenie vývoja, zvýšené napätie pri vývoji).

Softvéroví inžinieri používajú mnoho metód (tiež nazývané techniky alebo postupy). Každá z nich má cieľ, obyčajne zodpovedajúci podcieľu vývoja softvéru. Napríklad, štruktúrovaná (alebo objektovo – orientovaná) analýza má za cieľ pochopenie problému, ktorý sa rieši, DARTS má za cieľ architektúru procesu a štruktúrovaný návrh má za cieľ hierarchiu volaní. V každom prípade metóda pozostáva zo série krokov. Nedajte sa zaujať metódou, pri ktorej by ste zabudli na Váš cieľ. Necíťte sa vinný ak sa Vaše ciele zmenia prípadne úplne odstránia. Ak napríklad pochopíte problém po aplikovaní len polovice krokov metódy, zastavte sa. Na druhej strane potrebujete dobrý prehľad o celkovom procese softvéru pretože neskorší krok metódy, ktorý objaví zmeny v tomto princípe môže generovať niečo kritické pre neskoršie použitie.

Dobrý manažment motivuje ľudí aby vydali zo seba maximum, naopak biedny manažment demotivuje ľudí. Skvelá technológia (nástroje CASE, techniky, počítače, textové procesory a tak ďalej) nemôže vyrovnávať biedny manažment. Dobrý manažment môže skutočne produkovať kvalitné výsledky, aj keď prostriedky nie sú dostatočné. Softvér sa nestáva úspešným pretože má dobrý postup alebo používa významné nástroje (alebo je dôležitým výrobkom). Veľa softvérov bolo úspešných, lebo mali dobrý manažment a marketing.

Manažér má povinnosť robiť prácu čo najlepšie. Nie sú známe všeobecne „správne" štýly manažmentu. Štýl manažmentu musí byť prispôsobený situácii. Nie je nezvyčajné ak vedúca osoba sa správa krutovládne v jednej situácii a v druhej situácii dá súhlas po chvíľke váhania. Niektoré štýly sú vrodené. Ostatné sa môžu naštudovať. Ak je potrebné, treba si prečítať knihy a absolvovať krátke kurzy nejakého štýlu manažmentu.

Vo všeobecnosti často platí, že ľudia ktorí veria v čiastkové filozofie vyhľadávajú údaje, ktoré podopierajú jej myšlienky a do koša hádžu fakty, ktoré ju popierajú. Ak chce niekto presvedčiť ostatných o svojej pravde, väčšinou používa fakty, ktoré podporujú túto teóriu a zakrýva fakty, ktoré ju zapierajú alebo vnášajú pochybnosti.

Niekde sa môžete dočítať, že použitím metódy XY môžete zvýšiť výkon alebo kvalitu o 93 percent. Táto metóda mohla skutočne viesť k takémuto nárastu, ale išlo skôr o nezvyčajné a extrémne podmienky. Vo väčšine prípadov je pravdepodobný rapídny pokles efektívnosti až na úroveň, ktorá je menšia ako pri použití tejto metódy.

Šikovní ľudia s primeranými skúsenosťami, talentom a praxou sú kľúčom pre výrobu softvéru, ktorý uspokojí používateľov a náklady na jeho výrobu neprekročia rozpočet. Správni ľudia sú schopní dosiahnuť úspech aj so slabými prostriedkami. Nesprávni ľudia alebo ľudia s malými skúsenosťami a praxou s dobrými prostriedkami pravdepodobne zlyhajú. Podľa COCOMO sú tí najlepší ľudia štyri krát produktívnejší ako ostatní. Aj keď najlepší ľudia budú stáť 4 krát viac, ako ste počítali, pravdepodobne výsledný produkt bude lepší, ako keby ho vyrobili iní ľudia. Ak stoja menej, vyhráte 2 krát, pretože znížíte náklady a máte lepší produkt. Keď prímate nového zamestnanca majte na pamäti, že kvalita sa nedá ničím nahradiť. Firmy často konštatujú po pohovore s dvomi uchádzačmi, „Osoba X je lepšia ako osoba Y, ale osoba Y je dosť dobrá a bude nás stáť menej.". Nemôžete mať vo svojej organizácii iba tých najlepších, ale ak máte možnosť najať takéhoto človeka, urobte to, hoci ešte neviete, ako ho najlepšie využiť a zdá sa vám dosť drahý.

Tento princíp hovorí hlavne o tom, že na kritickú úlohu, činnosť je lepšie prideliť menej dobrých, skúsených odborníkov ako viacej neskúsených. Toto je Don Reifersov princíp manažmentu č. 6. Naproti tomu Manny Lehman varuje, že sa príliš nemôžete spoliehať na menej dobrých, skúsených odborníkov, lebo môžu odísť. Najlepšia rada teda je nezachádzať do extrémov, treba zvoliť strednú cestu, vhodne spojiť skúsených a neskúsených ľudí.

Ľuďom, ktorí pre vás pracujú, musíte dôverovať. Ak nie sú spoľahliví (dôveryhodní) (alebo keď im neveríte, váš projekt sa skončí neúspešne (zlyhá). Ak vám nedôverujú oni, váš projekt zlyhá tiež. Títo ľudia vycítia, že im nedôverujete, rovnako dobre ako vy vycítite, keď vám nedôveruje zase váš šéf.

Prvé pravidlo dôvery je počúvať ich. Máte veľa príležitostí počúvať svojich ľudí: napríklad, keď prídu do vašej kancelárie, aby vám porozprávali o probléme, ktorý majú; keď od nich potrebujete predbežný odhad softvérového vývoja; keď ste riaditeľom alebo vedúcim, ktorý chodí mimo iné aj medzi svojich ľudí. Kedykoľvek sa vaši ľudia s vami rozprávajú, počúvajte a hlavne počujte. To, čo vám hovoria, považujú za dôležité,…, alebo vám to hovoriť nebudú. Je veľa spôsobov, ako im dať najavo, že ich počúvate: kontakt očí; vhodná reč tela; zopakovať to, čo vám povedali tak, ako ste to pochopili vy; klásť vhodné otázky, aby ste sa dozvedeli viac informácií, atď.

Ak ľuďom dôverujete, budú sa správať tak, aby si vašu dôveru zaslúžili. Ak budete ľuďom preukazovať bezdôvodnú nedôveru, určite sa čoskoro začnú správať tak, aby ste im dôverovať nemohli. Ak dôverujete iným a nedáte im zámienku aby nedôverovali vám, budú vám veriť tiež. Prirodzená dôvera je základom pre úspešný menežment.

Ak sa vás niektorý z vašich zamestnancov opýta, či by dnes nemohol odísť s práce skôr a sám od seba navrhne, že si to odpracuje zajtra večer, mali by ste mu prirodzene vyhovieť. Nestratíte nič a získate vážnosť a náklonnosť u svojho zamestnanca. V živote existuje oveľa viac príležitostí byť zlým šéfom ako dobrým. Treba preto využiť každú šancu prikloniť sa k tej dobrej strane. Kto vie, možno raz budete potrebovať, aby vaši zamestnanci ostali v práci pár hodín dlhšie a dokončili niečo, čo potrebujete mať hotové.

Vaši zamestnanci budú pracovať omnoho lepšie, ak od nich budete očakávať maximum. Štúdia Warrena Bennisa presvedčivo dokázala, že čím viac očakávate, tým lepšie výsledky dosahujete (samozrejme v rámci istých obmedzení). Mnoho experimentov s rôznorodými skupinami, ktoré sa rozdelili na 2 podskupiny s rovnakým cieľom. V jednej podskupine sa požadoval maximálny prístup. V druhej postačoval priemerný. V každom experimente vyšlo, že skôr menovaná skupina prekonala druhú.

Máte mnoho spôsobov, ako ukázať, že od zamestnancov požadujete maximum: Sám im choďte príkladom (usilovne pracujte, buďte pyšný na to čo ste dokázali, nehrajte sa v práci počítačové hry). Poskytnite ukážkové výhody svojim zamestnancom, aby mali motiváciu pracovať naplno. Odmeňte vynikajúci prístup. Povzbudzujte, pomáhajte, lichoťte a pokúste sa inšpirovať slabších k väčším výkonom. Ak sklamú oni alebo vy, nájdite im vhodnejšiu pozíciu vo vašej organizácii alebo spoločnosti. Ak všetko zlyhá pomôžte im nájsť zamestnanie mimo vašej organizácie. Nemôžete ich nechať v tíme, ale musíte prejaviť ochotu pomôcť. Ak ich necháte tam kde sú, produkt bude nižšej kvality a zamestnanci budú predpokladať, že nižšia výkonnosť je prípustná.

Ak vasi ludia dlhe hodiny finisuju na softverovom produkte, mali by ste pracovat rovnako dlho. Nasledujuce riadky su toho dobrym prikladom:
Vasi zamestnanci budu velmi ochotne pracovat tvrdo a dobre ak budu vediel, ze v neprijemnych situaciach budete spolu s nimi. Moj prvy menezer pre tvorbu softveru bol v tom velmi dosledny, a to bola pricina vsetkych rozdielov v nasich postojoch. Pocas krizy sa Tom vzil do roly pracujuceho pre svojich zamestnancov. Zabralo to. Preto ak vasim ludom nemozete pomoct s inzinierskou pracou, dajte im vediet, ze ste ochotny zaistit objednanie pizze. Doneste im sodu, alebo im prineste vodu, proste im prineste cokolvek potrebuju. Prekvapte ich! O polnoci im prineste pizzu!

Niekedy nie je ľahké zistiť, čo ľudí motivuje k ich činnosti. Vieme, že ľudia sú rôzni a že na ich motivovanie možno použiť pozitívne aj negatívne stimulátory. Pozitívne stimulátory však často manažment prehliada. Prvým dobrým krokom k zisteniu toho, čo motivuje jednotlivých ľudi je počúvanie toho, čo hovoria. Ďalej je to už na manažérovi, pre akú taktiku sa rozhodne.

Väčšina produktívnych zamestnancov a spoločností majú tiché a súkromné kancelárie. Majú telefóny, ktoré môže byť nehlučné alebo presmerované. Sú izolovaní od bežných, neobchodných vyrušení. Na rozdiel od nich, vo všeobecných odvetviach, smerujú ku otvorým kanceláriám, ktoré redukujú výrobné náklady, ale dramaticky znižujú produktivitu a kvalitu. Pochopiteľne, poväčšinou názor manažerov je, že takéto otvorené kancelárie "uľahčujú komunikáci." To ale nie je pravda. "Odpútava to pozornosť a zvyšuje hluk."

Meranie projektov na človeko-mesiace, človek-týždne, či človeko-dni vedie k netušeným problémom. Je to veľmi citlivá záležitosť určiť výkon tímu pracovníkov jednoduchým vzorcom, hodnotiacim množstvo práce ľuďmi a časom na to potrebným. Ak by mal byť projekt dokončený za jeden rok šiestimi ľuďmi, znamená to, že sedemdesiatdva ľudí to urobí za „jeden" mesiac? Samozrejme, že nie!

Predstavme si, že máme desať ľudí pracujúcich na projekte, ktorý má byť dokončený o tri mesiace. Lenže tento projekt má „malý" problém, je v trojmesačnom sklze. Potrebujeme teda šesťdesiat človeko-mesiacov výkonu.(6 mesiacov x 10 ľudí) Našich desať pracovníkov vydá za tri mesiace tridsať človeko-mesiacov a ďalších desať pridaných pracovníkov za tri mesiace do dokončenia tiež tridsať človeko-mesiacov. Zdalo by sa, že problém je vyriešený a projekt sa vrátil naspäť do medzí svojho časového plánu.

V skutočnosti však pridanie desiatich „nových" ľudí do projektu môže spôsobiť ešte väčší sklz kvôli dodatočnému zaučeniu do problematiky a takisto kvôli zvýšeným nárokom na komunikáciu v rámci kolektívu.

Tento princíp sa zvyčajne nazýva Brooksov zákon.

V každom projekte môžete optimalizovať ľubovoľný faktor kvality. Optimalizáciou jedného faktora sa však vo všeobecnosti znehodnocujú niektoré iné faktory. V experimente vykonanom G.Weinbergom a E.Schulmanom dostalo päť tímov softvérových vývojárov rovnaké požiadavky, ale každý mal za úlohu optimalizovať iný parameter: čas vývoja, veľkosť programu, veľkosť použitého dátového priestoru, jasnosť programu a uživateľskú príjemnosť. Vo všetkých prípadoch, okrem jedného, mali tímami vytvorené programy najlepšie hodnotenie vzhľadom na parameter, ktorý bolo treba optimalizovať.

Ak poviete svojmu tímu, že všetko (plánovanie, veľkosť, udržiavateľnosť, výkon a uživateľské prostredie) je rovnako dôležité, žiaden z parametrov nebude optimalizovaný. Ak im poviete, že len jeden alebo dva parametre sú dôležité a zvyšok nie, budú optimalizovať len tieto. Ak im zadáte poradie parametrov podľa priority, toto poradie nemusí byť rovnako vhodné pre všetky situácie v projekte. V skutočnosti treba počas vývoja produktu stále robiť kompromisy. Pracujte so svojimi zamestnancami a pomôžte im pochopiť vaše priority a priority vašich zákazníkov.

Zber údajov je extrémne dôležitý pre predpoveď budúcich nákladov, odhad súčasného stavu projektu alebo organizácie, odhad efektu zmeny v manažmente, procese, technológii atď. Na druhej strane, zber dát je nevďačná robota (napríklad, ak vyžaduje od sovtwarových vývojárov robiť prácu navyše) a môže byť aj bezcenná pretože zber údajov ovlyvňuje údaje samotné. A navyše, údaje zozbierané od vývojárov ktorí ich nechcú poskytnúť, budú určite bezcenné, pretože je nepravdepodobné, že by nespolupracujúci vývojár poskytol zmysluplné údaje.

Najlepšou cestou na zber údajov je ich automatické zhromažďovanie, bez vplyvov závislých na vývojároch. Samozrejme, nedá sa to robiť vždy a so všetkými údajmi, ale mali by sme automatizovať zber údajov všade, kde sa to len dá.

Ak máme danú určitú sadu požiadaviek, môžeme sa rozhodnút implementovať program v ľubovoľnom z mnohých programovacích jazykov. Ked si zvolíme jazyk veľmi vysokej úrovne, spotrebujeme oveťa menej času, ako keď si zvolíme jazyk veľmi nízkej úrovne. Avšak, v dôsledku pevných nákladov na vývoj softvéru (sem patria napríklad náklady na používatelskú dokumentáciu, požiadavky, návrh a pod.), cena riadku kódu v skutočnosti narastie, ak si zvolíme jazyk vyššej úrovne! Pan Capers Jones toto vysvetľuje analógiou z výroby: Pri znížení počtu vyrobených jednotiek cena za jednotku stúpne, pretože pevné náklady musia byť potom absorbované menším počtom jednotiek.

Najviac používanými spôsobmi vyjadrenia produktivity v softvérovom inžinierstve sú: počet riadkov zdrojového kódu (SLOC - source lines of code) a počet funkcií (tzv. funkčných bodov) pripadajúcich na jednu osobu za mesiac. Pri obidvoch spomenutých spôsoboch merania produktivity narážame na problémy. Ak produktivitu meriame pomocou počtu riadkov zdrojového kódu môže sa zdať, že produktivita rastie priamo úmerne s počtom napísaných riadkov. To by znamenalo, že ak máme dva programy, ktoré poskytujú rovnaké funkcie je lepší ten, ktorý je dlhší. Samozrejme, platí to naopak. Meranie produktivity pomocou počtu funkcií rieši tento problém, pretože meria zložitosť problémov pomocou analýzy špecifikácie požiadaviek. Uvediem však príklad dvoch špecifikácií požiadaviek, ktoré sa líšia len v jednom bode: 1. Ak systém havaruje, bude zničená celá civilizácia. 2. Ak systém havaruje, budú mať mierne problémy dve päťročné deti. Vidíme, že prvý problém je oveľa závažnejší a vyžaduje si oveľa vyššiu produktivitu práce ako problém druhý.

Existuje niekoľko techník konverzie odhadu produktivity pomocou počtu riadkov zdrojového kódu na odhad produktivity pomocou počtu funkcií a naopak, ale nie je možné jednoznačne povedať, že niektorý z uvedených spôsobov je výhodnejší.

Znovu sa potvrdil fakt, že perfektná cesta neexistuje. Pri meraní produktivity je nutné používať vlastnú intuíciu a skúsenosti.

Je už zbytočné konštatovať, že nerealistické termíny sa nestíhajú. Naviac stanovovanie takýchto termínov podkopáva morálku, vyvoláva nedôveru a pocity vzdoru u pracovníkov a má aj ďalšie negatívne dôsledky. A tieto dôsledky robia nerealistické termíny ešte nedosiahnuteľnejšími.

V snahe dodržať plán sa však mnohokrát znižujú nároky na kvalitu, čo znižuje dôveryhodnosť softvérového priemyslu ako celku.

Problém nie je ani v nízkej produktivite softvérových inžinierov, ani v zlej práci manažérov. Problémom sú hlavne zlé odhady.

Toto sa moze zdat ako samozrejma rada. Na druhej strane, mnoho projektov sa zavazuje dodat svoj produkt v termine, ktory ja na 100 percent nedodrzatelny. Bary Boehm definoval tzv. "nemoznu oblast" ako pomer medzi predpokladanym casom na vyvoj produktu a mnozstvom potrebnych clovekomesiacov. Presnejsie, cas uplynuly od pisania specifikacie softverovych poziadaviek az po dodanie produktu nebude kratsi ako 2,15 krat tretia odmocnina clovekomesiacov. Devatdesiatdevat percent zo vsetkych dokoncenych projektov potvrdzuje toto pravidlo. Co Vas nuti mysliet si, ze to mozete zvladnut lepsie? Ak si to este stale myslite, mozete si pozriet principy 3, 19, 158, 159.

Gerhard Weinberg (Rethinking Systems Analysis and Design, New York: Dorset House, 1988 p. 32) vyjadril tento princíp výstižne: "Keď chceš niečo spočítať, musíš najprv o tom niečo vedieť." V článku spomína veľa ľudí, ktorí robia odhady pre rôzne záležitosti čo vlastne počítajú. Autor ponúka názorný príklad. Majme údaje týkajúce sa podielu softvérového priemyslu zaoberajúceho sa skôr údržbou ako vývojom. Ale ako rozoznáme, čo je údržba? Je "nový" vývoj, ktorý kompletne nahradí existujúci systém, považovaný za údržbu alebo vývoj? Je "modifikácia" existujúceho systému, ktorá zdvojnasobí jeho funkcionalitu udržbou alebo vývojom? Ked hladáš merítko pre svoj projekt, uisti sa, že to čo meriaš, sa vzťahuje k tomu, co chces dosiahnuť. To často znamená, že treba použiť viaceré metriky. Zapamätaj si: Ak všetci merajú niečo jedným spôsobom, tento spôsob nie je automaticky správny aj pre teba. Rozmýšlaj o svojej metrike. Keďže sa všetko dá sledovať (a vo väčšine prípadov zmerať), pozorne vyberaj, čo chceš sledovať (a merať).

Presnosť všetkých modelov odhadu ceny závisí od toho, ako je vám šítý na mieru. Nemôžete si však teraz prispôsobiť modely na odhad ceny, ak nemáte nazhromaždené údaje z predchádzajúcich projektov. To jediné vás teraz ospravedlňuje pri presnosti odhadu ceny. Ale čo zajtra? Nebudete schopný si prispôsobiť modely odhadu ceny, ak nezačnete zhromažďovať podrobné údaje už dnes. Tak na čo čakáte? Pamätajte na radu od Mannyho Lehmana: Menšie dáta, ktoré sa lepšie chápu a starostlivo zhromažďujú, modelujú a interpretujú, sú lepšie ako veľké množstvo údajov bez týchto vlastností.

Je relatívne jednoduché rozhodnúť o kritériách merania produktivity pre jednotlivca. (Samozrejme tieto kritériá nemôžu poskytovať presné výsledky, ako bolo zvýraznené v princípoch 142, 144, a 145.) Buďte si však vedomí že optimalizácia produktivity všetkých jednotlivcov nemá nevyhnutne za výsledok optimálnu produktivitu tímu. Prirovnajme to k basketbalovému tímu. Každý hráč môže optimalizovať vlastnú výkonnosť, až vždy trafí kôš keď má príležitosť. Avšak tím určite prehrá. Manny Lehman píše o jednom prípade keď úsilie pri vývoji softvéru viedlo k trojnásobnému zvýšeniu produktivity jednotlivca, ale spoločná produktivita sa vlastne znžila.

Sú tu dve veci z ktorých sa poučíme:

• Prvá, odlišné kritériá sú primerané pre odlišných ľudí.
• Druhá, meranie celkovej produktivity tímu sledovaním takých vecí ako schopnosť tímu vyriešiť mimoriadny(výnimočný) problém dokumentovaný za určitý čas.

Existuje všeobecný názor, že programátor môže vyrobiť v priemere X riadkov kvalitného kódu na osobu - za mesiac bez ohľadu na používaný jazyk. Teda ak programátor môže vytvoriť 500 riadkov kvalitného kódu za mesiac v Ade, tak by mohol tiež vytvoriť 500 riadkov kvalitného kódu za mesiac v jazyku symbolických adries. Pre opačné stanovisko pozrite C. Jones, Programming Productivity (New York: McGraw-Hill, 1986, Chapter 1). Skutočná produktivita je samozrejme značne rozšírená použitím vyšších programovacích jazykov, pretože 500 riadkov „ADA kódu" je oveľa viac ako 500 riadkov jazyka symbolických adries (assembler-u). Je teda zrejmé, že výber jazyka do veľkej miery ovplyvňuje udržovateľnosť (Princíp 193).

Keď začínate projekt mali by ste mať predstavu o tom, aký jazyk budú Vaši programátori používať. Toto je potrebné pre odhad riadkov kódu. Riadky kódu potom môžu byť použité na výpočet úsilia a času potrebného na realizáciu projektu.