All of these suggest higher entropy in the code, ie, a low signal to noise ratio.
There are a number of ways to attack this; probably the most effective one is to identify modules that have high defect rates -- defects tend to have a Pareto distribution, ie, 20 percent of the modules account for 80 percent of the defects. You build a test frame work for these modules, and re-implement them from a clean page, building good tests (using unit testing frameworks etc as appropriate) then fitting them back into the overall system.
I believe that software dying from the internal "technical reasons" you seem to have in mind is relatively rare. I can't really think of any examples; maybe Delphi (though that's not dead, just badly ailing).
It seems far more common for software to be die because
The underlying hardware or OS becomes obsolete and the software fails to make the transition (WordPerfect, Lotus 1-2-3)
A competing product offers superior features while the market leader stagnates due to complacency (Amiga)
The software becomes obsolete through "paradigm changes" (Encarta)
While the first two points are probably often partly the fault of quality problems (which make it too slow and costly to react to market changes), the latter isn't.
Not fixing critical bugs soon. Say you ship a new version that has a bug affecting 10 % of users. If you don't fix it promptly and ship a fixed version these users will be unable to fully use the program and will search for a replacement. When you finally ship the delayed fixed version they are gone.
发布评论
评论（6）
以下任何一项都明确表明您的系统已列入濒危物种名单：
保持项目活力的方法：
在软件库起死回生时，我必须将第一名丝带给 Objective- C。
Any of the following are clear indication that your system is on the endangered species list:
Ways to keep a project vital:
On sofware libraries coming back from the dead I would have to give the first place ribbon to Objective-C.
在此插入古怪的 Windows 笑话。
实际上有几个迹象：
所有这些都表明代码中的熵较高，即信噪比较低。
有很多方法可以解决这个问题； 最有效的方法可能是识别具有高缺陷率的模块——缺陷往往呈帕累托分布，即 20% 的模块占 80% 的缺陷。 您为这些模块构建一个测试框架，并从一个干净的页面重新实现它们，构建良好的测试（适当使用单元测试框架等），然后将它们重新安装到整个系统中。
Insert cranky Windows joke here.
There are really several signs:
All of these suggest higher entropy in the code, ie, a low signal to noise ratio.
There are a number of ways to attack this; probably the most effective one is to identify modules that have high defect rates -- defects tend to have a Pareto distribution, ie, 20 percent of the modules account for 80 percent of the defects. You build a test frame work for these modules, and re-implement them from a clean page, building good tests (using unit testing frameworks etc as appropriate) then fitting them back into the overall system.
我相信，由于您所想到的内部“技术原因”而导致软件死亡的情况相对较少。 我实在想不出任何例子； 也许是德尔福（尽管它并没有死，只是病得很重）。
软件死亡的情况似乎更为常见，因为
虽然前两点可能部分是由于质量问题造成的（这使得对市场变化的反应速度太慢且成本高昂），但后者则不然。
I believe that software dying from the internal "technical reasons" you seem to have in mind is relatively rare. I can't really think of any examples; maybe Delphi (though that's not dead, just badly ailing).
It seems far more common for software to be die because
While the first two points are probably often partly the fault of quality problems (which make it too slow and costly to react to market changes), the latter isn't.
不尽快修复严重错误。 假设您发布的新版本有一个影响 10% 用户的错误。 如果您不立即修复它并发布修复版本，这些用户将无法完全使用该程序，并将寻找替代品。 当您最终交付延迟的固定版本时，它们就消失了。
Not fixing critical bugs soon. Say you ship a new version that has a bug affecting 10 % of users. If you don't fix it promptly and ship a fixed version these users will be unable to fully use the program and will search for a replacement. When you finally ship the delayed fixed version they are gone.
当开发人员找借口_不_接触或支持该软件时。
When the developers are making excuses _NOT_ to touch or support the software.
唯一重要的衡量标准是源自您上面引用的“用户视角”的衡量标准。
最有可能的候选人是：
1. 支持请求增加，并且
2、销售额减少。
The only measure that counts is the one that derives from the "user perspective" you reference above.
The most likely candidates are:
1. Support request increases, and
2. Sales decreases.