Tämä ajattelu toimii yhä huonommin nykyaikaisessa ohjelmistoliiketoiminnassa, jossa tuotokset ovat käytössä määrittelemättömän pitkään ja ohjelmistot kehittyvät aktiivisesti ympäröivän maailman muutoksen mukana.

Elinkaarimallin perinteisten määreiden sijaan tulisi kiinnittää huomiota ohjelmiston muutosten ja kehityksen ketteryyden säilyttämiseen. Vaivattomasti eteenpäin kehittyvä ohjelmisto mahdollistaa alhaisemmat kehityskulut ohjelmiston koko elinkaaren aikana.

"Ei ole järkevää tehdä yksinkertaista ohjelmaa liian monimutkaisella tavalla"

Muutosten hintaa kuvaa hyvin englanninkielinen termi "Cost of Change". Jokainen uusi ominaisuus tai toiminnallisuus on muutos ja elinkaarimallin tulisi lähteä tavoitteesta pitää muutosten hinta hallittuna myös ohjelmiston ikääntyessä.

Perustan muutosten hinnalle asettaa projektiin tehtävän työn hinta. Projektin alun linjauksilla voidaan kuitenkin vaikuttaa merkittävästi tarvittavaan työn määrään kutakin muutosta kohden. On tärkeää hahmottaa ohjelmiston lopullinen kokoluokka, jotta arkkitehtuuriin liittyvät valinnat voidaan tehdä oikein.

Ei ole järkevää tehdä yksinkertaista ohjelmaa liian monimutkaisella tavalla, jolloin jo ensimmäinen julkaisu on kallis ja aikataulu venyy. Toisaalta monimutkainen ohjelmisto hyötyy ehdottomasti hyvin tehdystä jaottelusta – modulaarisuudesta, joka mahdollistaa ison kokonaisuuden helpon hallinnan. Liian yksinkertainen ohjelmiston rakenne isoksi kasvaneessa ohjelmistossa vaikeuttaa puolestaan muutosten tekoa ja lisää riskiä virheille.

Myös teknologisilla valinnoilla on suuri vaikutus elinkaaren kokonaiskustannuksiin. Teknologiat tulee pystyä valitsemaan perustellusti ja tarkoitukseen soveltuen. Ohjelmistokehittäjien ikuinen kiista parhaasta ohjelmointikielestä ei ehkä sittenkään ratkea teknisin meriitein, vaan lähin vastaus löytynee kulloinkin elinkaarikustannuksia laskevan kylterin taulukkolaskennasta.