Iraila. Goizeko bederatziak. Udal kiroldegiko izen emateak zabaltzen diren unea. Unibertsitateko ikasle bat autobusean doa, mugikorra eskuan, igeriketa saioan plaza lortu nahian. Etxean, mahai gaineko ordenagailu baten aurrean, hirurogeita hamabost urteko pertsona bat dago, adinekoentzako gimnasia taldean izena eman nahian. Ez dute elkar ezagutzen, baina pantaila bera dute aurrean, une berean, gailu desberdinetan, beste bi mila lagunekin batera. Sistemak denei erantzun behar die, justu une horretan. Urteko gainerako egunetan ia inork ez du erabiliko.

Pantaila horren atzean, ordea, gehiago dago. Kiroldegian bertan norbait ari da lanean goiz osoan, izen emateak pilatzen diren bitartean. Harrera mahaira hurbildu denari lagundu behar dio, mugikorrik ez duelako edo ez delako moldatzen; taldez aldatu nahi duenari erantzun; deskontuak zuzen aplikatzen diren egiaztatu. Berak ez du bizkortasuna behar, gertatzen ari den guztia batera ikusteko modua baizik. Eta bada gaur inork ikusi ez duen beste norbait: urtarrilean, bere plaza beranduago iritsi zen bati eman ziotela erreklamatuko duena. Bederatziak eta lau minutuan zer gertatu zen frogatu ahal izateko, nor den nor egiaztatu eta urrats bakoitza berretsi behar da, autobuseko ikasleari klik gehiago eskatuz. Bizkortasuna, ikuspegi orokorra eta froga: hiru behar, sistema bakarra. Eta hori guztia «ez da nahikoa» esango dizute sistemaren arduradunek.

Izan ere, aurreko guztiak aurtengo irailerako balio du. Datorren urtean tarifak alda daitezke, deskontu berri bat sortu, edo plazak iristeko ordenaren arabera banatu beharrean zozketa egitea erabaki dezake Udalak. Duela bost urteko oinarriak idatzi zituenak ez zuen ezer gaizki egin: testuingurua aldatu da. Eta sistema ezin da zaborretara bota eta hutsetik berregin urtero. Egokitu egin behar da.

Hor dago, hain zuzen, ingeniaritza, ez kodea idaztean. Softwarea egiten dugunok badakigu sistema batek urte asko iraungo dituela, eta horregatik hasieratik bereizten saiatzen gara zer mantenduko den finko eta zer aldatu daitekeen urtero. Plazak egongo dira beti, norbaitek bere burua identifikatu beharko du beti, zerbait kobratuko da beti. Zenbat kobratzen den, nork ordaintzen duen gutxiago eta plazak nola banatzen diren, aldiz, urtero alda daitezke. Bigarren horiek kodearen barruan idatzita geratzen badira, aldaketa bakoitzak sistema ukitzea eta dena berriro probatzea eskatuko du. Kodetik kanpo geratzen badira, Udaleko norbaitek alda ditzake inori deitu gabe. Erabaki hori diseinatzen den egunean hartzen da, oraindik inork ez dakienean noiz eta zer aldatuko den etorkizunean. Horregatik egiten ditu softwarea diseinatzen duenak hain galdera bitxiak: «Hau beti horrela izango al da?», «Egongo al da inoiz beste tarifa motaren bat?».

Eta kiroldegi batez ari gara. Pentsa egunero erabiltzen dituzun sistemetan, bankukoetan edo ospitalekoetan: hamarkadak daramatzate martxan, behin eta berriz egokituz, eta programatzen eman zituzten hilabeteak aspaldi geratu ziren atzean. Softwarea egitea programatzea dela esaten denean, beraz, zatirik errazenaz bakarrik ari gara. •