Ihmisillä on ikävä tapa tarrautua omistamiinsa asioihin. Joskus it-projektista tulee kuin oma lapsi, jota on vuosien varrella kasvatettu ja johon on investoitu merkittävä määrä rahaa. Tappiokammon takia huonossa tilassa olevasta projektista voi olla yllättävän vaikea luopua, varsinkin jos siihen on kulutettu paljon rahaa ja rakkautta.
Joskus verkkopalvelu on järkevintä heittää roskiin ja aloittaa se täysin alusta. Esimerkiksi valekoodarin rakentamaa, ylisuunniteltua ja tarpeettoman monimutkaista sovellusta voi olla yhtä vaikeaa ylläpitää kuin serkkupojan virittelemää, yhden tiedoston ja yhden funktion vastaavaa. Tällöin uuden rakentaminen rinnalla voi olla halvin ja aikaasäästävin vaihtoehto. Mutta mikään ei takaa uuden projektin onnistumista. Tutkimusten mukaan jopa 2/3 uusista it-projekteista valmistuvat aikataulustaan myöhässä.
Vaihtoehtoisesti, sovellusta voi pikkuhiljaa, pala palalta, refaktoroida. Tämä tarkoittaa sitä, että sovellusta uudelleenkirjoitetaan pieni osa kerrallaan, ja olemassa olevat toiminnallisuudet pyritään säilyttämään sellaisenaan. Refaktoroinnin pääasiallisena pyrkimyksenä on helpottaa sovelluksen parissa työskentelyä. Samalla mukaan voi jopa tuoda parannuksia. Tällöin projektissa pysyy selkeä suunta, riskit ovat pienempiä ja kokonaisuus pysyy paremmin kasassa. Refaktoroidessa on huomioitava uusien ja vanhojen toimintatapojen samanaikaisuus, joka saattaa hidastaa tekemistä ja lisätä vikoja. Uusia toimintatapoja täytyy kurinalaisesti tuoda käyttöön, sekä samalla myös arvioida niitä sopivan itsekriittisesti. Projektin alkutilasta riippuen, refaktorointi voi olla erittäin hidasta ja vaivalloista. Aina sekään ei kannata.
Kuinka päättää, refaktoroidaanko sovellus vai aloitetaanko alusta? Tätä päätöstä tehdessä on tärkeää analysoida käytössä olevan palvelun kriittisyys ja potentiaalisen uuden palvelun rakentamisen kesto ja kustannukset. Uutta tehdessä pitää miettiä, mitä vanhalle tapahtuu sitä odotellessa. Yleensä vanhasta palvelusta täytyy siirtää ja synkronoida dataa, jotta esimerkiksi siinä olevat käyttäjät siirtyvät automaattisesti uuteen. Hyvin kriittisen palvelun, kuten laskutusjärjestelmän, uudelleen rakentaminen kerralla on luonnollisesti suurempi riski kuin yksinkertaisten kotisivujen.
Voiko uusi palvelu olla jossain määrin erilainen, ja miten palvelun käyttäjät siihen suhtautuvat? Käyttäjien siirtymistä helpottamiseksi kannattaa harkita, voiko uusi ja vanha sovellus toimia rinnakkain siirtymäajan, vai päivitetäänkö kaikki kerralla. Mitä laajempi uudistusprojekti, sitä huonompi ennuste voidaan sen onnistumiselle antaa.
Projektin tila kannattaa tiedostaa tarpeellista itsekritiikkiä käyttäen. Jos siihen ei tietotaito riitä, on suositeltavaa auditoida eli tarkastuttaa se luotettavan tahon toimesta. Uusi verkkopalveluprojekti voi aina mennä pieleen. Vanhan verkkopalvelun tekohengitys voi tulla kalliiksi.
