Tarjottaessa ohjelmistokehittäjälle valintaa kahdesta erityökeikasta – joko uuden palvelun tekeminen alusta alkaen, tai vanhan projektin jatkokehittämistä ja ylläpitoa – valitsee kehittäjä hyvin todennäköisesti ensimmäisen vaihtoehdon. IT-konsulttifirmoilla on usein samanlainen linja. Monen firman liiketoiminta koostuu vain uusien digitaalisten palvelujen luonnista. Tämän takia tilaajilla on toisinaan vaikeuksia löytää halukkaita tekijöitä tekemään päivityksiä vanhoihin projekteihin.
Ohjelmistokehittäjän näkökulmasta kokonaan uuden palvelun rakentamisen houkuttelevuus on selvää: silloin pääsee käyttämään itselleen sopivia teknologioita ja työvälineitä, sekä ohjaamaan projektin kulkua. Uudesta projektista saa hienon referenssin portfolioon. “Legacy-projektien” jatkokehitys ja ylläpito sen sijaan tuntuu monesta turhauttavalta, jopa omalle uralle haitalliselta toiminnalta.
Sen lisäksi että vanhojen projektien jatkokehittäminen voi tuntua turhauttavalta, niin kehittäjät tuntuvat kokevan niiden sisältävän riskin oman työuran kehittymiselle. Käytetyt teknologiat ovat usein vanhoja eikä niiden osaaminen paranna omaa CVtä. Myös työn luonne on erilainen uusiin projekteihin verrattuna: aikaa kuluu ylläpitoon ja korjaamiseen, ja vain pieni osa ajasta on käytettävissä uuden kehittämiseen. Ominaisuuksien saaminen valmiiksi on hitaampaa ja monimutkaisempaa, sillä vastassa itselle vieras arkkitehtuuri. Vanha koodi tuntuu aivan väärällä tavalla tehdyltä. Jokainen muutos voi rikkoa palvelun odottamattomalla tavalla, ja se on huomioitava jatkuvasti, sillä palvelu on käytössä.
Ei kuulosta kovin hauskalta. Kuvailemani ongelmat eivät ole lopulta niin suuria, kuin miltä ne aluksi vaikuttavat.
Vaikka jatkokehitysprojektiin lähteminen tuntuukin huonolta valinnalta, ei se minusta ole sitä. Moni ennakkoluulo osoittautuu vääräksi. Oikealla asenteella ja valmistautumisella vanhasta projektista saa enemmän irti kuin kokonaan uudesta projektista.
Ensimmäiseksi on hyväksyttävä se tosiasia, että vanhan päälle tekeminen on hitaampaa ja monimutkaisempaa. Muutosten vaikutukset on selvitettävä tarkoin, toisin kuin julkaisemattomissa uusissa projekteissa. Tekemisen hitaudesta ei kannata syyttää itseään
Seuraavaksi kannattaa selvittää miksi asiat on tehty niin kuin ne ovat. Oudolta näyttävien ratkaisujen taustalla olevat syyt eivät aina ole teknisiä, vaan ne voivat johtua liiketoiminnan asettamista rajoitteista. Ratkaisuja ei kannata tuomita huonoiksi ensisilmäyksellä. Todennäköisesti joku muu ihmettelee tekemiäsi muutoksia samalla tavalla parin vuoden päästä.
Toisten kehittäjien tekemästä koodista oppiminen jää harvoin huomioimatta. Ihmisillä ja firmoilla on eri tapoja toteuttaa asioita. Sekä erityisen hyvät että myös huonot tavat tehdä asioita kannattaa painaa mieleen. Jatkossa hyviä ratkaisuja voi soveltaa itse seuraavissa projekteissa. Huonot ratkaisut tunnistaa nopeasti, jolloin niiden käyttöä tietää välttää tulevaisuudessa.
Mitä vanhojen teknologioiden kanssa työskentelyyn tulee, ei uudempien käyttäminen välttämättä ole helpompaa. Uudet kielet ja kirjastot pyrkivät ratkaisemaan vanhoissa olleita puutteita ja ongelmia, joten niillä pitäisi olla helpompi tehdä asioita. Uuden ympäriltä kuitenkin puuttuu se sama kehittäjäyhteisö ja ekosysteemi mitä vuosien tai vuosikymmenien ikäiseltä teknologialta löytyy. Koodin kirjoittelu vanhoilla kielillä ja kirjastoilla on tuskin kovin virkistävä kokemus, mutta silloin voi luottaa siihen, että joku muukin on paininut vastassasi olevien ongelmien kanssa aikaisemmin.
Vanhan projektin jatkokehitykseen mukaan hyppääminen on haastavaa ja työlästä, eikä kaikille sopivaa. Mutta siihen pystyvät ovat mielestäni konsulttien parhaimmistoa. He ovat hyviä ratkaisemaan ongelmia ja ymmärtämään isojen kokonaisuuksien toimintaa.
Julkaistu 03.05.2019 – Arttu Ekholm
