Signs of Dying Software [closed]

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

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 2

Insert cranky Windows joke here.

There are really several signs:

• increasing defect arrival rate
• higher cost per 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.