

Why your software project will slowly die without continuous updating - jrs235
http://blog.versioneye.com/2014/02/18/why-your-software-project-will-slowly-die-without-continuous-updating/

======
Aqueous
Pretty funny - the scenario you describe is pretty much exactly what happened
when I inherited the management of a site that gets about 257,000 uniques per
day - millions per year. It was built using Rails 2.0 without any attempt to
upgrade it since it was first deployed. Since I really don't have time - my
time is taken up managing 3 to 4 to 5 other projects at the same time as
managing this web site - I've been unable to spend the pretty large amount of
time it would take to bump the application up two major versions so that
incremental updates become easier. Nor does the company want to pay me to do
that.

I think a lot of applications reach an early end of life because of the nature
of subcontracting. You build the application, your contract reaches an end,
and then the company wants to stop paying for upgrades, seeing them as
optional. They will only pay you to keep administering the existing site
indefinitely.

But where I might differ? Maybe that's the way it should be, short of being
reckless (you should always be applying security updates). Technology and
methodology changes so much in three or four years that retrofitting new
features on the old, crufty application seems like going backwards. Ultimately
the company ends up wanting to rebuild the whole thing. In the case of the
application I'm talking about, almost all of its features would be done better
by an existing CMS system. I would feel sick to my stomach adding new CMS
features that I know would work more beautifully inside of off-the-shelf CMS
software that has been extended to complete the custom task.

