Ohjelmistoprojektin 7 kuolemansyntiä – 6. osa: vanhassa vara parempi

Listasimme softaprojektin 7 kuolemansyntiä, joita kenenkään ei pitäisi olla tuomittu toistamaan. Toiseksi viimeisessä osassa puhutaan kaavoihin kangistumisesta. 

Uskomus: 

Jos tiettyä tekniikkaa on käytetty jo silloin, kun lerput ja matriisitulostimet olivat muotia, on se pätevä edelleenkin. Ja jos vanhasta järjestelmästä säilytetään mahdollisimman paljon, uusi valmistuu nopeammin!

Totuus:

Älä valitse valmiiksi kuollutta tekniikkaa. Lisäksi mieti ennen uuden hankkeen aloittamista pitkään, miksi edellisestä tuli tunkio, ja korjaa näistä syistä ainakin yksi uudessa projektissa. 

Älä jumitu vanhoihin tapoihin

Protokeissi pöydällä ja tärkeä päätös edessä: halutaanko proto ulos suit sait sukkelaan (riippumatta siitä, onko tehdylle työlle käyttöä myöhemmin) vai valitaanko tekniikat, joiden avulla voidaan rakentaa ensiaskelista alkaen jotain tulevaisuuden kestävää? Jos ideasi on jo validoitu, on ilmeistä valita tekniikat sen mukaan, että ne hengittävät myös softan vauva-ajan jälkeen. 

Pahin synti on poimia tekniikkakoriin jotain jo kuollutta. Vaikka COBOL on kirmaillut tuolla jossain vuosikymmenien ajan, se ei välttämättä ole paras valinta kestävää ohjelmistokehitystä ajatellen. Korporaation koodikellarissa voi istua joukko devaajia, jotka ovat jumittuneet vain osaamiinsa teknologioihin. Tällöin koko projekti saatetaan pakottaa toimimaan hapantuneilla työkaluilla silloinkin, kun se ei olisi lopputuloksen kannalta järkevää.

Tekkivalinnat pitää tehdä niin, että ne vastaavat yrityksen tavoitteita ja visiota sekä tänään että huomenna. Ne eivät kuitenkaan saa olla liian raskaita firman tarpeisiin nähden. Tuleeko ohjelmistossa olemaan esimerkiksi valtava määrä prosessoitavaa dataa? Entä kuinka paljon skaalaamista tarvitaan?

Jos softaa on tehtailtu tuotekehitysholveissa aiemminkin, kannattaa ennen uuden projektin aloittamista uhrata aikaa pohdinnalle, miksi edellisestä tuli ongelmajätettä. Uudessa projektissa voi sitten ottaa oppia virheistään. 

Yrityksen tarpeiden ja tekniikan tuoreuden lisäksi on syytä miettiä, kuka tämän kaiken koodaa. Vaikka parhaat devaajat pystyvät omaksumaan melko vaivattomasti uusia työkaluja, voi liian eksoottisen tekniikkavalintojen kanssa jäädä jumiin tiiminrakennusvaiheessa. Jos tekniikan taitavan tiimin löytäisikin, ei aina ole kiveen hakattua, haluavatko kyseiset koodarit tätä tekniikkaa käyttää. 

Puuttuuko projektistasi kokeneita devaajia? Ota yhteyttä Raketin komentokeskukseen!

Seitsemännessä osassa aliarvioimme loppukäyttäjää. Lue sitä odotellessa aiemmat synnit: 

Ohjelmistoprojektin 1. kuolemansynti – resurssi on resurssi

Ohjelmistoprojektin 2. kuolemansynti – enemmän koodia!

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