I originally posted this thought as an update on LinkedIn and since that time I thought I'd expand on this idea a bit. In this article I'll answer the question: what is the software project half-life?

The Software Project Half-Life

The software project half-life is a term invented by yours truly which is defined as follows:

The point at which a functioning software project is so out-of-date that the level of effort (LOE) required to maintain it goes from manageable to involved.

If left uncorrected a project in this state will eventually require monumental effort to update.

Severely elevated risk, cost, and time required to return the project to a healthy state will be persistent and unavoidable.

It's difficult to pinpoint exactly where a specific software project's half-life is due to the complexity and uniqueness of what goes into a given project, coupled with the amount of change that takes place in the software ecosystem on a day-to-day basis however the more external dependencies a given project relies on and the larger and/or sophisticated the project, the more energy will be required to keep that project maintained over time.

Full Software Project Decay

So what does a complete project decay look like?

In deliberately bleak terms a full software project decay might include some or all of the following characteristics (if you have additional characteristics, add them in the comments):

• Business and technical knowledge is absent due to the original team no longer being available. This can be mitigated to some extent with documentation but when the original team is completely gone count on large gaps of knowledge being entirely missing from the project.
• External dependencies the project relies on are no longer under active development and, to make matters worse, prevent the project from being updated. This may be mitigated to some extent by keeping the project up-to-date or nearly up-to-date. The more integral and complex the component, the harder it will be to work around this problem but better to deal with this issue over time rather than during an emergency.
• Further development as it relates to new features, critical defect remediations, and/or security vulnerability concerns (etc) is halted entirely as the engineers and other team members acquaint themselves with the application as it exists in its current state.
• The process by which the application is developed, tested, and released needs to be re-established.
• Firefighting abounds.
• Stress levels are elevated.
• Over time team member attrition increases.
• Expensive consultants are contacted with hopes that they can address the problem quickly.
• At some point the project may be viewed as having completely failed.
• A complete rewrite is discussed as an option.

This is a very bad place to be but it happens. One reason a situation as described above can occur is that a project which has been released and is considered to be feature complete is (or eventually becomes) treated as if it is at it's end-of-life and this is a costly mistake to make.

Maintenance Mode Implies Continuous Investment

A simple solution to ensure that a given software project avoids reaching the state described above is to keep it up to date to some extent even when it's no longer under active development. In other words, the project should be considered to be in maintenance mode until it's officially retired and that means continuing to perform work on the application at scheduled times in order to avoid surprises and to ensure that the application always remains in a healthy state. This includes all aspects of the development process: the people involved, the project itself, the code, testing, releasing new versions of the software, etc.

Conclusion

If you've read this far and see some of the characteristics mentioned in this article in your own projects then the time to act is right now. Implementing a strategy for software development in your organization that includes continuous improvement, continuous investment, and by simply taking a proactive view toward your development practice can start to pave the way toward having healthier projects overall and an overall lower total cost of ownership.