Ohjelmistoprojektin 7 kuolemansyntiä – 2. osa: enemmän koodia!
Vältä ohjelmistokehityksen sudenkuopat, osa 2/7! Ensimmäisessä osassa kirjoitimme tekijöiden tuottavuuseroista ja oikean kehittäjän valinnasta. Toisessa osassa pohditaan koodin määrän ja laadun suhdetta ja sitä, mihin kallis aika kannattaa käyttää.
Jokainen tietää, millaisia lapsia syntyy hosumalla. Sama pätee softaprojekteihin. Aikataulupaineet ajavat tekemään hätäisiä purkkafiksejä, vaikka fiksumpaa voisi olla kirjoittaa jokin osa koodista uudelleen. Heikosti harkituista koodiriveistä ei ole iloa kenellekään.
Uskomus:
Mitä nopeammin uutta koodia kirjoitetaan, sitä aikaisemmin projekti valmistuu.
Totuus:
Määrä ei korvaa laatua – ajattelemalla ensin ja koodaamalla vasta sitten päästään rivakammalla sykkeellä maaliin. Sinkoilulla ja välttävän työn korjailulla päästään nopeasti iltauutisiin.
Softaprojekti on oivallusprosessi
Useimmissa ohjelmistoprojekteissa valtavat määrät kallista etukäteissuunnittelua ei ole tarpeen, ja siksi niitä koodataan iteratiivisesti. Aluksi toki kannattaa tehdä rujohko prototyyppi, jolla yritetään löytää ongelmia, joita ei pelkässä miettimisvaiheessa tule ajatelleeksi.
Softakehityksessä järjestelmän toiminnallisuuteen voidaan tehdä suuriakin muutoksia koko projektin ajan – toisin kuin vaikkapa siltaa tai kerrostaloa rakennettaessa.
Ohjelmistoprojekti onkin usein oivallusprosessi, jonka edetessä opitaan yhdessä, mitä pitää kehittää ja mihin suuntaan. Matkan varrella tarpeet voivat vaihtua, ja samalla välietapit ja aikataulut muuttuvat. Ketterät kehitysmetodit taklaavat osan ongelmista mutta kokonaan ne eivät poistu. Iteraatiokierrosten määrää voi sen sijaan voi vähentää käyttämällä erityisen hyviä kehittäjiä!
Koneeseen kosketaan, kun ajattelutyö on valmis
Yleensä devaajat käyttävät enemmän aikaa vanhan koodin ymmärtämiseen kuin uuden koodin kirjoittamiseen. Työ siis nopeutuu, kun koodikanta on kunnossa.
Liian herkästi softaan päädytään lisäämään uusi feature, vaikka jokainen uusi rivi koodia on lisää kasvualustaa bugeille ja kustannusta koodikannan ylläpitämiseen. Huonon koodin päälle tehdään helposti vain purkkakorjauksia, eikä kukaan ole niistä ylpeä tai ota vastuuta koodikokonaisuudesta. Jos koko koodikanta on samanlaista höttöä, osa tiimistä alkaa varmasti etsiä uusia töitä.
Koodin refaktoroinnille kannattaa varata aikaa ja kirjoittaa testejä alusta asti. Projektin johto saattaa olla tietämätön refaktoroinnin tarpeesta, vaikka se nopeuttaa devaamista, estää koodin homehtumista ja vaikuttaa kehittäjien tyytyväisyyteen.
Enemmän ei siis aina ole enemmän; tiimin koko tai koodaajan vauhdikkuus eivät takaa tiimin tuottavuutta. Pahimmillaan ne takaavat vain tuhottoman määrän tusinakoodia ja teknistä velkaa. Maksatko sinä mieluummin määrästä kuin laadusta?
"Sehän on parasta työtä, kun koneeseen ei koske vaan ajattelee. Koneeseen kosketaan sitten, kun ajattelutyö on valmista.” Anonyymi rakettitieteilijä
Jos maksat mieluummin laadusta kuin määrästä, ole yhteydessä – vastaamme raketin lailla!
Lue myös nämä:
Ohjelmistoprojektin 1. kuolemansynti – resurssi on resurssi
Ohjelmistoprojektin 3. kuolemansynti – konsultti kallis, oma työntekijä halpa
Ohjelmistoprojektin 4. kuolemansynti – no kun halvalla sai
Ohjelmistoprojektin 5. kuolemansynti – kaikki muu paitsi välitön bisneshyöty on turhaa
Ohjelmistoprojektin 6. kuolemansynti – vanhassa vara parempi
Ohjelmistoprojektin 7. kuolemansynti – aliarvioi loppukäyttäjät