Signs of dying software

Question

What are the signs that the software is dying?

---

How does a developer detect early warnings to save a piece of software from death?

From a user’s point of view, I think it’s pretty clear - that they cannot use effectively, they will be rubbish.

In addition, the software may die due to this code — architecture, coding style, code base size, code base organization, and programmer quality.

I want to know how to listen to the signs of dying software and take corrective action. Are any known software examples dead because no developer listened to the signs? Any examples of persistent save software?

Answer 1

Any of the following clear signs that your system is on the endangered species list:

• A single point of failure is allowed to exist (only one person understands it)
• Resources are not allocated by management to correct errors.
• No active development for six months.
• No production cycle per year
• Base products / vendor libraries out of support
• Resources withdrawn from the project and not replaced more than twice per quarter
• Environmental changes (e.g. higher user level) are not fixed
• Performance is not measured and tuning does not occur regularly (performance degrades)
• Infrastructure changes are configured (OS, DB, EQUIPMENT)
• Users created a job around because of flaws, frustrations, or errors in your system.
• The user base is falling

Ways to save a life project:

• Interact openly and directly with your leadership.
• Clearly reflect defect rates and quantify them in terms of management costs.
• Automate as many assembly, testing, packaging and deployment cycles as you can
• Modulate the system as much as possible
• If there are clear indicators and application settings, if necessary
• Understand what your users consider the most critical and respond to these needs.

In software libraries returning from the dead, I would have to provide Objective-C first place tape.

Answer 2

Insert a funny Windows joke here.

There are really several signs:

• defects arrival rate increase
• higher repair cost per defect
• higher cost for a new feature

All this implies higher entropy in the code, i.e. low signal to noise ratio.

There are several ways to attack this; probably the most effective is the determination of modules with high defect coefficients - defects, as a rule, have a Pareto distribution, i.e. 20 percent of modules account for 80 percent of defects. You create a test frame operation for these modules and re-implement them from a clean page, creating good tests (using, for example, the unit testing framework, etc.), and then picking them back into the general system.

Answer 3

I believe that software dying from internal "technical reasons" that you seem to have in mind is relatively rare. I cannot think of any examples; possibly Delphi (although it's not dead, it just hurt badly).

It seems much more common for software to die because

• The underlying hardware or OS becomes obsolete and the software does not complete the transition (WordPerfect, Lotus 1-2-3)
• The competing product offers superior features while the market leader stagnates due to complacency (Amiga).
• Software becomes obsolete with “paradigm shift” (Encarta)

While the first two points are probably often part of the quality problem (which makes it too slow and expensive to respond to market changes), the latter is not.

Answer 4

Do not fix critical errors soon. Let's say you submit a new version with an error affecting 10% of users. If you do not fix it quickly and do not send the corrected version, these users will not be able to fully use the program and will look for a replacement. When you finally send the delayed fixed version, they are gone.

Answer 5

When developers make excuses _NOT_ to relate to or support software.

Answer 6

The only measure taken into account is the one based on the “user perspective” that you indicated above.

The most likely candidates are:
1. The support request is increasing, and
2. Sales are down.

Answer 7

Read this blog post from Jeff Atwood (one of the creators of this site). It's great to read on dying software.

http://www.codinghorror.com/blog/archives/001252.html