How to determine web application end of life? [closed]

Question

This question could bring a lot of opinions to the table, but what I will like to get is a set of measures that will help me and my company determine the end of life of a product that we sell.

We sell a CMS system, with this system we create a few sub-products

• Websites
• Proposal Creator
• Marketing Campaign Tracker

We are ready to start our road planning (for 2010 and 2011) and we are trying to figure when will be the end of the life of our application. Some of you might think that a very well architected application (I don't think our application is well architected) does not need to have an end of life, but this app that we are using goes back at least 6-7 years and has almost no documentation (real life). At this moment only ONE person knows how to change core functionality (scary).

Please advice,

Geo

---

Thanks to All! I really appreciate your comments, opinions and thoughts on this topic.

I will address a few of the post back questions in the list below

• There is one developer that is able to maintain the core functionality of our product. (only and only one)
• There are two developers that are able to increase functionality to a certain point. Both developers are constrained by the limitations of the core product, and they both have to work within those limits.
• A very important note. The product that we are considering to put to end-of-life is for the most part being built by a contractor. The contractor is the only developer able to maintain the core functionality. We only develop on top of the contractor framework.

I will keep adding answers while I read you all responses.

Answer 1

Since application is very well architected you may not want to retire it and loose all investment you have made to date.

Here are my suggestions:

• Have a junior developer join this current developer.
• Dump most of future updates on junior developer (with assistance from sr. developer)
• Ask junior developer to do the documentation of his work
• Ask Sr. developer to review documentation

Over period of time, you have another person who can support this application and it will be documented as well. Now you won't need to kill your own very well architected application with your own hands.

.

Extending this solution with Jefferey suggestion below("Sometimes rewriting is a good investment.")

If you still want to drop current application and re-write it, you still need to document existing system and create requirements for new system based off it.

Using documentation of current and proposed system, you may want to see if you can incrementally module by module upgrade (re-write) components. This is possible if application is very well architected.

---

As per your (Geo) comments

Geo's organization has custom third-party (with one and only one contract developer) CMS application that implements below business requirements and is paying licensing fee for support and use of his code.

• Business requirements for CMS
• Websites
• Proposal Creator
• Marketing Campaign Tracker

Here are my suggestions

• Create module by module detailed use case document for this project. Your developer can do this or would be ideal to have a seperate business analyst for same.
• Hire a Sr. Developer to evaluate if open source CMS can handle all or most of your requirements (e.g. Joomla, Drupal, etc.).
• Most important thing here would be ability to migrate your existing data to new system. You may need help from your existing contract developer to do this.
• You may have to update business process or workflow to use new system.
• Modules that cannot be implemented using open source CMS may be required to be implemented using custom website.

Much of it also depends on your business relation with existing contract developer and license agreement. What you are facing is a vendor lock in scenario. You may want to further research on solutions to eliminate this vendor lock in situation.

Answer 2

This is just my opinion, but if this is a product that you are selling, then it all boils down to business prospects. If the product doesn't sell, then drop it. If the product has a future, then invest in it, and make it the best software you can by refactoring, rewriting, or whatever you have to do. If you have loyal customers or a strong brand, then that's worth protecting.

Sometimes rewriting the whole thing in another technology is a good investment, if the current software has a successful design that can be copied, has a strong brand, and if it can be done right.

Answer 3

The application reached end of life the moment it shipped without any sort of documentation. Begin development now, and you might want to consider replacing the person who knows the original system. If they've gone 6/7 years without creating any sort of documentation whatsoever, they're not someone you'll want in your company.

Answer 4

The only kind of documentation which will extend your system's life are things which stay consistent as the system changes in its lifetime, like test suites, self-diagnostic tools, code comments, declarative contracts like interfcaces, and automatically generated documentation.

Other manually managed documentation artifacts, like manuals, developer guides, architecture documents, data formats tend to become out of date in proportion to the amount of documentation. I would not count these as factors which increase your application life expectancy unless you have already factored in the cost of maintaining them.

If you can't "afford" developer redundancy to maintain the application reliably, there's no way you can afford to keep the documentation up to date. Lack of documentation is really a technical debt you've decided, perhaps unconsciously, to take on. If a longer lifecycle is a requirement, then the cost of that has to factor into meeting that requirement.

Answer 5

To make a long story short: I am in a comparable situation.

• As long this application is something like a cashcow, but the company can't afford (or intend) to develop of a new application, it will not die before customers decide to buy a fresher system.

• Rewriting without (documented) requirements is almost impossible.

• At least the experience of specialized departments, should be documented in a way that is useful for further developments.

• If you have to maintain this application, you should introduce interfaces between modules, to reduce overall complexity. So old modules no matter how messie they are, don't care if you have to plugin new functionality.

Answer 6

Even if it is very well designed and functioning, the fact that it has no documentation and depends on one person for its life, means the product has very well entered an unmaintainable state. This is not a good sign. I would agree that the product is long past "End of life"

Answer 7

These are the kind of things I might consider when deciding if a system might be going "end-of-life":

Is the functionality that this system provides available to end-users in a cheaper, more reliable or easier to use form? If not now, then when is this likely? Is this product therefore viable in the longer term?

Is this written in a technology that customers would steer away from as it would be awkward to interface into their products, or require them to run "obsolete" platforms? Would it give a potential customer the impression that your company is significantly behind the times e.g. VB6 is probably just still OK, even in 2010, but requiring Win16 compatibility probably isn't.

Can you hire good people that know the underlying technical platform at a reasonable cost? On older tech, it might be that there are lots of people that know the platform but see it as a dead-end and will ask for a premium salary if their career is going to languish in the doldrums whilst they work on it.

If it matters to you, is the development platform still supported by the vendor? Are you going to be constrained on what hardware or OS you can run it on if the vendor is no longer updating it? Likewise, are there security holes in the platform that may need to be updated? Even niche Open Source products can suffer from this. Once a product goes out of favour and core developers move onto fresh projects, it can be difficult to get fixes done by the community.

If it is supported, are the vendors charging you a premium for supporting an older platform? If not now, then how long before they do?

How difficult is it to integrate new technologies into it to take advantage of current trends that offer enriched functionality to end-users to keep you competitive? Do you care about this? It may not matter if you're essentially running a closed system.

How difficult is it to release functional changes to it without extensive "shotgun" changes that ripple across the whole system? This comes back to how modular the system was designed to be in the first place. If you're no worse that your competitors in getting features to market then you're probably OK.

What would be the cost of re-writing the system? How does this compare to how much cheaper it would be to maintain or increase of sale revenue? It might not be economically feasible to do a whole re-write. If the development platform is sound then you could just try more of a refactoring approach. This is where having a good test-suite and documentation helps.

Answer 8

I went through a similiar process. We had a web app that had run for almost 8 years. In that time a lot of maintenance was done, extending it in ways we hadn't envisioned. However, the core was good and it was still able to be stretched.

What pushed us over was the maintenance cost. Finding people with the right skill set was easy 8 years ago. Today, no one wants to work in those environments; not even us :)

After analysis, we knew we could replace it within 12 months with identical functionality AND that this time spent would pay off quickly.

So, we used screen shots as our functional requirements, revamped the look and feel, and were even able to deliver increased functionality. We also looked at usage data to identify parts that were either rarely or never used and trimmed those, and focused more attention on the parts that were used.

Ultimately, we were successful. In part because everyone on the team was well versed in the new technology so there was little need for learning. Other contributing factors included a well thought out design. I think we spent 3 months just in design before writing anything.

The final factor was that our app is modular. So we were able to chunk it out in sizes small enough to have a combination of short delivery schedules with a downtime / analysis period between each deliverable. This ensured we were on the right path at every stage.