i am always fascinated by the backward compatibility of vfp, and that really helps me to do my job with much less headache.  i am a solo developer who not only have to build the app, but also have to support it.  being backward compatible make it possible for me to gradually "upgrade" my app at a pace that my client and i can afford.  set behavoir allows you to control the feature globally, where as individual commands such as report form allows fine-grained control. 

i "re-use" this idea in my app.  whenever i introduce some controversial changes to my client's app, i condition it with an ini entry, so that i can switch back and forth with or without the change easily.  this gives me a peace of mind because if the new feature doesn't work or my client changes thier mind, i don't have to rush to my client's office to fix it.  i can fall back instantly without any code change, recompile or testing.  this buys me time.

in the code, rather than modifying the original source code to add the new feature, i clone the existing code first and then modify the clone to add the new feature, and then condition which portion of the code to run with the value of the ini entry.  this way i know for sure the old code will work as before (because i haven't changed it) in the case i have to fall back to it.  this reduces the amount of regression testing.  rolling it back to a previous version from source control will also work but i generally find that more troublesome to do in practice.

in order for this to work, the new feature will have to be designed properly so as to make it compatible with the old feature.

with this approach, both my client and myself are happier because i become less reluctant to accept change requests, and my client is welcomed to change their mind back and forth.



Leave a Reply

Your email address will not be published. Required fields are marked *