
Should Code Die On Schedule? - imgabe
http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-04.html#e2009-04-15T21_00_50.htm
======
Tangurena
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.

------
gojomo
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.

