Jos olisin alalla vaikkapa mikkisoftalla ja vaikkapa isona pomona, niin tekisin koodareiden kanssa vain sellaisia sopimuksia jossa palkka tulee vain toimivasta koodista ja toimivasta koodista tehdystä ohjelmasta. Mitä enemmän koodissa ja ohjelmassa on virheitä sitä enemmän myös palkka laskee 
Eli koodarin duuni olis tulossidonnaista. En oikein tajua että mikä vaikkapa mikkisoftalla on pointtina maksaa paskasta ja toimimattomasta koodista / ohjelmasta ja syytää rahaa kaivoon.
No, se n kyllä melko varma että tuolla näkemyksellä ja asenteella ei kovin isoa pomon pallia lohkeaisi. Miten sitten määrittelisit tuon "toimivan koodin"? Onko koodi toimivaa silloin kun se on määrittelydokumentin vaatimukset täyttävä? Entä jos tuo määrittely oli jo tehty väärin, eli koodi toimii kyllä määrittelyn mukaan mutta määrittelyvaiheessa oli tehty virhe, joka johtaa siihen että lopputuote toimii väärin/vajavaisesti/ennustamattomasti? Kenen vika on että määrittelydokumentti tehtiin väärin? Oliko aikaa liian vähän määrittelyyn? Eikö asiakas tiennyt mitä tilaa, jonka takia määrittely tehtiin väärin ja jonka takia saatiin huonoa softaa.
Ohjelmistoalalla harvoin pätee ns. perinteisen teollisuuden laatumäärittelyt, ja -varmennusmenetelmät, yksinomaan jo sen takia että lopputuote ei ole mitään konkreettista materiaalia, esim. auto tai talo.
Sitten kun tuollaista valmista ohjelmistokomponenttia vielä halutaan käyttää (lue: muokata) tarkoitukseen, johon sitä ei alunperin tehty? Onko se fiksua? Tuleeko se halvemmaksi? Kyllä ja ei? Tässä nyt rautalankaesimerkkinä esimerkiksi: rakennusfirmalta tilataan kerrostalo. Piirustukset tehdään, talo rakennetaan, ja se on kaikenpuolin kunnossa. Sitten joku haluaa siirtää tuon talon kokonaan toiseen ympäristöön, lisätään vielä kuusi metriä seinästä ulkonevat parvekkeet vanhoen yksimetristen sijaan ja pistetään asukkaat muuttamaan sisään. Hyvä idea?
EI kaikki oli niin yksioikoista, kuin mitä saattaa (internetin nojalla) näyttää.
