Mikä on ohjelmistotuotteen arvo, ja miten arvoa voidaan kasvattaa?

Ohjelmiston käyttöpäivän vaikutus yhteisön missioon on arvon perusyksikkö. Ohjelmiston käyttöikä ilman muutoksia muodostaa tulevaisuuden arvon perusosan. _Tavoitekäyttöikä _potenssiin sen helppous, että ohjelmiston koodi saadaan taivutettua tulevaisuuden tarpeisiin, muodostaa suurimman osan ohjelmiston arvosta, sillä ilman muutoksia käyttöpäivän arvo organisaation missiolle pienenee sitä mukaa kun maailma muuttuu organisaation ympäriltä.

Ohjelmiston koodi muodostuu suuresta joukosta abstrakteja konsepteja jotka on konkretisoitu paperille matemaattisen kaavan muotoon. Toisin kuin fysiikassa ja matematiikassa, ohjelmistokehityksessä käsiteltävät abstraktit konseptit ovat kuitenkin hyvin läheisessä suhteessa ihmisten ajatuksiin ja tulkintoihin, joiden suhteiden toisiinsa odotetaan muuttuvan, eikä tulkintojen "oikeutta" voida mitata itsenäisesti.

Viime vuosikymmeninä tietokoneiden teho oli suurin haaste. Ohjelmistokehittäjät keskittyivät muokkaamaan ongelman muotoon, jossa tietokone pystyi kaikkine rajoituksineen ymmärtämään ja käsittelemään sen. Nykypäivänä tietokoneet ovat niin paljon nopeampia, että ollaan edetty paljon vaikeamman ongelman ratkaisemiseen: kuinka voidaan rakentaa laajempia ohjelmistoja, sekä niin että ne voivat tehdä enemmän että niin että niiden ylläpitoikä on pidempi. Sen sijaan, että ongelma pitää selittää tietokoneelle, se pitää pukea sellaiseen muotoon että sekä tietokone että toiset ihmiset ymmärtävät sen samanaikaisesti.

Jotkut ovat kokeilleet sitä, että ylläpidetään samaan aikaan erillistä ongelmakuvausta tietokoneelle, ja erillistä ihmisille, mutta se ei ole vielä toiminut, sillä kuvaukset väistämättä poikkeavat toisistaan oleellisesti. Kohtuullisesti toimivassa nykymallissa itse kuvaus siitä mitä tehdään jaetaan tietokoneen ja ihmisen välillä, mutta ihmisille kirjoitetaan väliin lyhyitä kommentteja siitä, miksi ongelma ratkaistaan niin, ja mikä ratkaisun laajempi merkitys on.

Ohjelmiston koodi saadaan taivutettua tulevaisuuden tarpeisiin sitä paremmin, mitä enemmän sen rakennukseen valittu tapa abstrahoida ongelma muistuttaa tulevaisuuden tulkintoja. Käytännössä menestyneet tavat abstrahoida kokonaisia ongelmia ovat keskittyneet siihen, että kokonainen ongelma jaetaan sellaisiin palasiin, jotka muodostuvat alakäsitteistä jotka muuttuvat samassa prosessissa tai saman yhteisön sisällä tapahtuvien muutosten muovaamina.

Esimerkiksi monien ohjelmistojen pitää käsitellä raha-asioita. Valuutat, tilitapahtumat ja valuuttasummat voivat tällöin muodostaa oman yksikkönsä. Tällöin, kun Suomi siirtyy Euroon, voidaan olla aika varmoja siitä, että sovelluksen muuntamiseen vaadittu työmäärä voidaan selvittää tutkimalla pelkästään tätä yksikköä, eikä koko sovellusta tarvitse käydä läpi. Raha-asiat ovat kuitenkin varsin helppo esimerkki, sillä useimmat käsitteet eivät ole käytössä yhtä laajalti ja yksiselitteisesti kuin raha ja vaihdannan välineet. Useimmat konseptit ovat vähemmän mietittyjä ja niistä on eri ihmisten ja organisaatioiden välillä eri tulkintoja.

Lomakkeet joissa on tekstikenttiä ovat tyypillinen tapa hallita ihmisten toiminnan tuottamaa tietoa, jonka hallinnassa pitää olla tarkkana. Sovelluksen ratkaisemasta ongelmasta riippumattomien yleisten haasteiden selvittäminen itse ei ole enää kovinkaan usein tarpeen, vaan löytyy valmiita runkoja (framework) jotka muotoilevat ongelman ja tarjoavat siihen kokonaisratkaisun tavalla, joka jättää auki mahdollisuuden luoda itse esimerkiksi ilmaisukykyisempiä sovelluskohtaisia kenttiä lomakkeeseen.