Usually when one discusses project lifetimes, it is almost always in the context of describing the time and events between when a project is conceived, when it is delivered, and all that stuff that happens between those two fenceposts.
But project delivery is just the beginning of a project’s lifetime.
By a far sight.
My longest lived project, gauged by years in production and useful life, was eighteen years (an MS-DOS based electrical estimation project that was retired in 2007). My current “dean” of active software projects, running in pretty much the same form I completed it, is an engineering design product called SAND that I developed for the Bank of America (and now actively maintained by HP) – in continuous production since 1998.
In short, software projects can have surprisingly long lifetimes.
That’s why when I hear designers and developers say that they’re doing something because it’s expedient and that they will go back later and “do it the right way”, I cringe. Because practical experience tells me we usually never get a chance to “redo something the right way” once a project gets out into the wild.
Some developers – quite wrongly – expect their responsibilities and obligations on projects to end the moment their contractual obligations free them to move on the next thing.
A great many software projects would have happier endings if developers took their responsibility and obligation in products with all the gravitas that would normally go along with birthing something that could have a potential lifetime in decades.
Most of us consider our spans of administrative control to cover only that period from one paycheck to the next.
And our software is all the worse for it.
This isn’t a paean to Work as Life – only a lament that as developers we often don’t envision that our creations will have lives that far outrun our ability to dream.
Logorrhea 