Should Code Die On Schedule?

What a terrible idea. It is one that is appealing to developers for the simple reason that we get paid to write this stuff. From the point of businesses, it makes less than no sense and makes planning just about impossible.

From a slightly similar system (undersea fiber optic cables):

Like many other telephony-related technologies, traffic forecasting was developed to a fine art a long time ago and rarely screwed up. Usually the telcos knew when the capacity of their systems was going to be stretched past acceptable limits. Then they went shopping for bandwidth. Cables got built.

That is all past history. "The telecoms aren't forecasting now," Mercogliano says. "They're reacting."

This is a big problem for a few different reasons. One is that cables take a few years to build, and, once built, last for a quarter of a century. It's not a nimble industry in that way. A PTT thinking about investing in a club cable is making a 25-year commitment to a piece of equipment that will almost certainly be obsolete long before it reaches the end of its working life. Not only are they risking lots of money, but they are putting it into an exceptionally long-term investment. Long-term investments are great if you have reliable long-term forecasts, but when your entire forecasting system gets blown out of the water by something like the Internet, the situation gets awfully complicated.

http://www.wired.com/wired/archive/4.12/ffglass_pr.html

When the business ecosystem gets chaotic/fractal, investments stop, because they can't make the 25-year plans to pay off their investments. And they can't make 1-year plans to pay off investments, so those investments stop getting made as well.

This is a neat thought experiment, though it strikes at the heart of what makes coding so interesting as an economic activity -- that once you get a valuable process 'right', the code + electrons lets you keep milking it for value at a larger scale, or for a longer period, with negligible marginal effort.

A milder form of the practice could be to apply code review to not just new code, but the oldest code in the system -- just in case opportunities for high-payback projects are being overlooked.