Signs of Dying Software

Question

What are signs that software is dying?

---

How does a developer find early warnings to save a piece of software from dying?

From user perspective, I think it is pretty clear - What they can not use efficiently, they will trash.

Apart from this the software can die because of it's code - the architecture, coding style, size of codebase, codebase organization and quality of the programmers.

I want to know how to listen to the signs of a software dying and take corrective actions. Any famous examples software being dead because no developer listened to the signs? Any examples of dying software being saved?

Answer 1

Insert cranky Windows joke here.

There are really several signs:

• increasing defect arrival rate
• higher cost oer defect repaired
• higher cost per new feature

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

• Single point of failure permitted to exist (only one person understands it)
• Resources are not allocated by management to fix defects
• No active development for six months
• No release cycle in a year
• Underlying vendor products/libraries go out of support
• Resources taken off a project and not replaced more than twice in a quarter
• Environmental changes (higher volume of users for example) are not remediated
• Performance is not measured and tuning does not regularly occur (performance degrades)
• Infrastructure changes are looming (OS, DB, HARDWARE)
• Users have created work arounds due to flaws, frustrations, or bugs in your system
• Users base is falling

Ways to keep a project vital:

• Engage your management openly and directly
• Report defect rates accurately and quantify them in terms of cost to management
• Automate as much of the build, test, packaging, and deployment cycles as you can
• Modularize the system as much as possible
• Have clear metrics in place and tune the applicaiton if necessary
• Understand what your users find most critical and address those needs

On sofware libraries coming back from the dead I would have to give the first place ribbon to Objective-C.

Answer 5

When the developers are making excuses _NOT_ to touch or support the software.

Answer 6

Read this blog from Jeff Atwood (one of the creator of this site). A wonderful read on a dying software.

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

Answer 7

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.