Tärkeä osa ohjelmistokehitysprojektia on sovelluksen elinkaaren ja jatkokehitettävyyden miettiminen.
Valitettavasti tämä vaihe saattaa joskus unohtua välistä.
Kerron varoittavan esimerkin.
Eräs konsulteistamme meni hankkeeseen, johon tuotti palveluita myös ulkopuolinen yksikkö.
Vaikka hankkeessa oli aiemmin käytetty tiettyä teknologiavalikoimaa, ulkopuolinen yksikkö oli päättänyt, että uusi palvelu toteutetaan poikkeavilla teknologioilla. Myös tietokantakerros vaihdettiin.
Konsulttimme tehtävänä oli automatisoida palveluiden infraa. Hän ihmetteli, miksi ympäristöön tuotiin tietokantaratkaisu, joka ei sopinut nykymalliin ollenkaan.
Kun muu järjestelmä alkoi valmistua, uudesta tietokantakerroksesta nousi esiin pahoja suorituskykyongelmia.
Konsulttimme selvitti asiaa.
Kävi ilmi, että uuden palvelun toteuttaneella tiimillä ei ollut riittävää osaamista valitsemistaan teknologioista. He olivat halunneet kokeilla jotakin uutta, mutta unohtaneet ottaa huomioon yhteensopivuuden.
Samoin selvisi, ettei asiakkaalla ollut käsitystä teknisen velan määrästä eikä suunnitelmaa, mitä sille tulevaisuudessa tehdään.
Auts.
Ongelmien ratkominen jäi sisäisen tiimin harteille.
Osa palvelusta saatiin tuotua olemassa olevaan arkkitehtuuriin.
Mutta pahin pullonkaula, tietokanta, jäi palveluun kaikkien riesaksi. Se hankaloitti vielä pitkään jatkokehitystä ja kulutti huomattavan summan asiakkaan rahaa.
Mitä tästä voi oppia?
Ainakin sen, että jotta asiakas saisi teknisesti kestäviä ratkaisuja, pelkkä kehittäjien pinnallinen osaaminen ei riitä. Tarvitaan myös kokemusta.
Kokemusta vaikkapa siitä, että on itse yrittänyt ylläpitää huonolaatuista koodia.
Nimittäin sitten ymmärtää omakohtaisesti miten tärkeää on, että koodi on jatkokehitettävissä senkin jälkeen, kun kehittäjä on siirtynyt pois hankkeesta.
Kokemus säästää asiakkaan resursseja pitkällä aikavälillä.
Se on kestävää ohjelmistokehitystä.