TARGO TENNISBERG: Arendaja peaks olema professionaalne ja tellijat hoiatama, et ta endale jalga ei tulistaks

Üks võimalus tarkvara kirjutada on lihtsalt kõik funktsionaalsed nõuded täita: tarkvara peab täitma seda, seda ja seda kasutuslugu, kui ta seda teeb, siis on valmis. Teine võimalus on aga pöörata tähelepanu mitmesugustele mitte-kohe-nähtavatele asjaoludele, näiteks jõudlus, skaleeruvus, hallatavus, laiendatavus, jälgitavus, töökindlus, turvalisus jne. Igaüks neist lisab esialgsele töömahule ehk paarkümmend protsenti. Alati pole kõik need asjaolud tähtsad ja mingit hulka neist (või ka kõiki) võib ignoreerida. Häda on selles, et pealtnäha näeb tarkvarasüsteem ikka samasugune välja ja teeb samu asju. Probleem tekib siis, kui mõne sellise nõudega pole arvestatud, aga seda läheb siiski vaja. On näiteks vaja mingit uut funktsiooni lisada, aga selle lisamine on tohutult kallis või siis teeb uus funktsionaalsus olemasolevat pidevalt katki.

Ideaalis oleks vastutus mõlemapoolne: tellija oleks neist nõuetest teadlik ja oskaks nende täitmist nõuda ja kontrollida, samuti peaks arendaja olema professionaalne ja tellijat hoiatama, et ta endale jalga ei tulistaks. Reaalselt elame aga maailmas, kus tihti ei osata mittenähtavatele nõuetele tähelepanu pöörata ja ka parimad insenerid pigistavad silma kinni, kui on tarvis vähempakkumisega hankeid võita.

Kui kaua „säilib“ hea tarkvara ja kas headus peegeldub ka hinnas? Maailmas on tarkvarasid, mis on aastakümneid töös olnud ja mida ka pidevalt edasi arendatakse. Uue funktsionaalsuse lisamine nii, et tarkvara mittefunktsionaalsed omadused ei halveneks, on enamasti keerulisem, kui selle naiivsel viisil realiseerimine. Vahe oleneb asjaoludest, aga võib olla näiteks 1,5-2 kordne. Teiselt poolt on korralikult kirjutatud tarkvarale palju lihtsam täiendavaid funktsioone lisada, see ei lähe nii kergesti katki ja seal on lihtsam vigu parandada. Ja muidugi pole vähetähtis see, et meil pole vaja seda tarkvara regulaarselt uuesti algusest peale valmis kirjutada.

Tagantjärele mittefunktsionaalsete omaduste lisamine on võrreldes kohe hästi tegemisega mitmeid kordi kallim. Eriti halb on aga see, et selle „tagantjärele korda tegemise“ hinnakordaja kasvab tarkvara keerukuse kasvades veelgi – uut funktsionaalsust lisades kaevatakse end sageli järjest sügavamasse auku. Seda auku nimetatakse ka „tehniliseks võlaks“ – midagi jäi alguses tegemata, olgu siis kokkuhoiust või teadmatusest, kuid millalgi tuleb võlg siiski tasuda, lisaks ka intressid. Sageli juhtub ka, et võlg on liiga suureks kasvanud ja tarkvara on pankrotis – lihtsam on teha uus, kui vana korda saada.

Mida rohkem muutuvad nõuded tarkvarasüsteemile, seda tähtsam on, et tarkvara oleks hästi hooldatav ja laiendatav. See tähendab, et kood peab algusest peale olema kirjutatud arvestusega, et hiljem võivad tulla mitmed teised programmeerijad, kes tahavad seda lahti võtta, ümber seada ja teistmoodi kokku panna. Tellijatele, kes töötavad muutliku turu või seadusandluse tingimustes, on eriti tähtis, et nad oskaks arendajalt vastavaid omadusi nõuda ja nende täitmist ka kontrollida.

Hyperintelligent Aliens tegevjuht Targo Tennisberg (varasemalt Bondora süsteemiarhitekt, Nortali äriüksuse juht ja Microsofti juhtivarendaja) esineb 12. juunil Äripäeva ITuudiste korraldataval parimate praktikate seminaril „Kuidas edukalt rakendada tulevikutehnoloogiaid ja nutikalt juhtida strateegilisi IT projekte?“ Registreeru sündmusele siin: http://www.ituudised.ee/ITprojektid