Do you use good code over backward compatibility?
  v1.0 Posted at 26/04/2018 7:22 AM by Tiago Araujo

Supporting old operating systems and old versions means you have more (and often messy) code, with lots of if or switch statements. This might be OK for you because you wrote the code, but down the track when someone else is maintaining it, then there is more time/expense needed.

When you realize there is a better way to do something, then you will change it, clean code should be the goal, however, because this affects old users, and changing interfaces at every whim also means an expense for all the apps that break, the decision isn't so easy to make.

Our views on backward compatibility start with asking these questions:

  • Question 1: How many apps are we going to break externally?
  • Question 2: How many apps are we going to break internally?
  • Question 3: What is the cost of providing backward compatibility and repairing (and test) all the broken apps?

Let's look at an example:

We have a public web service /ssw/webservices/postcode/
If we change the URL of this public Web Service, we'd have to answer the questions as follows:

  • Answer 1: Externally - Don't know, we have some leads:
    We can look at web stats and get an idea. 
    If an IP address enters our website at this point, it tells us that possibly an application is using it and the user isn't just following the links.
  • Answer 2: Website samples + Adams code demo
  • Answer 3: Can add a redirect or change the page to output a warning Old URL. Please see www.ssw.com.au/ PostCodeWebService for new URL

Because we know that not many external clients use this example, we decide to remove the old web service after some time.

Just to be friendly, we would send an email for the first month, and then another email in the second month.  After that, just emit "This is deprecated (old)."  We'll also need to update the UDDI so people don't keep coming to our old address.

We all wish we never need to support old code, but sometimes the world doesn't go that way, if your answer to question 3 scares you, then you might need to provide some form of backward compatibility or warning.

From: John Liu www.ssw.com.au
Subject: Changing LookOut settings

The stored procedure procSSWLookOutClientIDSelect (currently used only by LookOut any version prior to 10) is being renamed to procSSWLookOutClientIDSelect. The old stored procedure will be removed within 1 month.
You can change your settings either by:

  • Going to LookOut Options -> Database tab and select the new stored procedure
  • Upgrading to SSW LookOut version 10.0 which will be released later today

Related rules

    Do you feel this rule needs an update?

    If you want to be notified when this rule is updated, please enter your email address: