Browse Prior Art Database

System and method to automatically purging out the deprecated or defunct code and add them on-demand at run time

IP.com Disclosure Number: IPCOM000244662D
Publication Date: 2016-Jan-06
Document File: 5 page(s) / 66K

Publishing Venue

The IP.com Prior Art Database

Abstract

System and method for seamlessly removing the obsolete/deprecated functionality/function for better adaptability and integration and add them on demand without any extra effort. The removed functionalify can be added on demand by placing the loadable modules generated from the removed/obsolete code.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 5

System and method to automatically purging out the deprecated or defunct code and add them on-demand at run time

Problem Statement:

A small foot print is a dream of every enterprise product. However almost all enterprise products / software systems become bulkier by adding new features over a period of time. This can be due to meeting new functionality requests or adopting to new technologies. For example, when a product is getting adopted to cloud or mobile space, some of the features might become irrelevant. Same will be the case while adopting to newer operating systems/environments. One of the major challenge in this activity is to remove the source code of irrelevant / obsolete / deprecated functionality. However most of the products 'bypass' the source code instead of completely removing. Few reasons for this safe approach could be :
A1. Fear of customers using them. Especially if the product is old. Had a 'long standing customer' or 'heavily paying customer'

A2. Fear of breaking other required functionality. Due to inter-dependency of modules in a product.

A3. Lack of product skill / knowledge. Probably due to attrition of team members.

A4. Lack of confidence on the test suite. i.e., there may not be enough tests to confirm the source code is indeed 'dead' and not reachable from any execution path.

Following is one 'safe approach'.

)

Suppose the code to be removed is in a different module (module2). In such a case module2 is unnecessarily shipped, installed and loaded during runtime. All this for telling 'This function is deprecated'.

1


Page 02 of 5

Let us do some math: Sl
No Cause

Effect

B1 Assume funcObsolete() is of
100 lines Assume the size of binary equivalent when compiled as 4KB

B2

Assume the 'FunctionalityTOdeprecate' has 20 such functions.

Unwanted binary size will be 20 * 4K = 80KB

Assume the product deprecated 10 funcitonalities as obsolete / deprecated.

Total unwanted foot print is 10 * 80K = 800KB

B3

B4

Assume the product has 1000 customers running 100 instances.

Total memory wastage is 1000 * 100 * 800KB = 80000000 KB or 80000 MB or 80 GB
Imagine CPU wastage

B5

If only 50% (generally it will be 100% for a functionality to be deprecated) of the customers are not using the obsolete functionality 50% of 80GB = 40 GB of dead binary code is loaded. If the ToBeDeleted code is a separate module, then wastage will be even more

Existing Solution:
Even with so much negative impact, products doesn't remove them completely. Mainly because of the lack of confidence to remove OR fear of breaking existing functionality. There...