I don't think this is a good idea. Forcefully rewriting working systems is a recipe for disaster.
Yes, stagnated systems are also a huge problem, but I don't think setting a hard limit on a system's age is the solution.
Yes, stagnated systems are also a huge problem, but I don't think setting a hard limit on a system's age is the solution.
Any one with Kotka's level of experience must know that many companies don't rewrite their legacy systems because it is extremely expensive. Otherwise they would do it all the time. You might save in maintenance costs, but the cost of rewriting is much larger.
You usually rewrite software when it no longer does what you want it to do, or the cost of improving it exceeds the cost of rewriting. It can certainly take more than 13 years for the scales to tip in favor of a massive rewrite, especially for backend systems upon which many other systems rely.
I work in the public sector (K12 Education) and I find that many of the problems I deal with are the same impetus for the policy they've used.
You're right, however- I think it should be on a case-by-case basis. It's obvious that heavily used end-user desktops/laptops/etc need to be upgraded at least once every 13 years, but some server hardware might last a bit longer than 15 or so.
I guess it all boils down to cost/reward.
http://b2b.cbsimg.net/blogs/data-center-infographic__ashx.jp...
http://www.techrepublic.com/blog/data-center/infographic-the...
The replacement cycle is closer to 3 years than 15 in the private sector for hardware.
Major software releases [including those with full rewrites] happen more often than once every 15 years as well.
I'm not sure I buy the full rewrite bit simply because I know things can go horribly, horribly wrong with those. I'd be happier with a 5 year refresh cycle.