I have been suporting software applications for more than 2 years now .
My experience with software applications range from Huge pile of scripts, Java Web applications,
Swing Client applications, Java based non-web Server-aplications etc ....
According to me , there are several relatively small decisions which go a long way in making any applications easily maintainable .
1)Seperation of business data and Configuration information .
I have been supporting an application which has a folder in unix , where there are number of PDF's stored .They are essentially business data .But part of the folder structure has a number of configuration files thrown in here and there .
Yes , thrown in literally .
There were more than 50 XML files and 20 property files distributed across some 30 folders .
Iam not saying it was not logical , it was organized logically .
But it made a maintence engineers and Users to doubt QA testing .
It becomes quite tough and complex to clone the application in QA .
Once people dont have confidence on testing , application is headed to bad times .
People give complex and nasty fixes , afraid to change anything more than what is required to fix the visible bug(Which more often tip of the iceberg) .
They spend hours making sure their change does not affect other scenarios , not think once if that scenario is currently working correctly or not .
They become too catious to do anything that remotely affect any other business user other than one who raised teh bug .I have seen scenareos where others users soon come in with the same problem and we endup giving the same nasty bug fix to each of them .Instead of doing a simple common design change .
So we end up 100 lines of code , 5 versions of the files and 5 UAT on a bug to hide away from users .
To fix it ,it takes 10 lines 1 version and 1 UAT to fix .
But since nobody really wants to approve , the entire process becomes self damaging .
Its a vicious circle , once something like this is done for say 5 years , application is becomes tough to maintain .Even the nasty bug fix carefully written not touch anything , ends breaking something .Bugs become more and more complex and often a bug represents a multiplicity of factors like wrong data , incorrect program logic , wrong design , network issue etc ....
Ability to confidently clone the application in a Test enviroinment .
High confidence on QA testing and subsequent approval are very important .
Else nobody is confident of touching the application , but software , like everything in the universe needs to well kept and compensated for the increase entropy
(read as "spend money on it" :-)) ) .
2)Seperation of Configuration information clearly into functionality specific configuration and enviroinment specific configuration .
This very important because , it adds to movability of the applications across servers , databases and middlewares .
What is Application of configuration ?
Typically , application mode , email template or list of people to email events .
Debug level and channel informations , and all other application settings .
What is Enviroinment configuration ?
Database instance name and encripted password , unix folder path , middleware connection parameters .
List seems small . but its easy to mix them up into a complete mess .
Example , a template file path in a property file having the full unix path ( a perfect mix of enviroinment and application configuration )
i.e.,
BlanketPurchareTemplate=/usr/awd10/a123app/config/pdfs/blanketpurchase.pdf
I know , its a simple example.
But imagine changing 15 configurations like this each time you have to replicate production.
You will want to avoid , and yes there will start all problems .
QA starts looking like a different program than production .
If enviroinment configuration is seperate , u can safely ignore them while Cloning .
Seperate is not just seperate file or table .There is no point in having 10 more files in 10 more folders , nooooo .
Group them together in 2 seperate folder structures , so any one can tar and move what they want , easily and confidently .
It should be kept in mind that other factors listed below are also equally important .
1)Consistent Code conventions and design conventions
Its harder to acheive in any long running applications , almost impossible if it was supported and enhanced by multiple vendors .
But we can live those issues most of the time :-) .
2)Documenting the reasons for a particular design(this more important than documenting the design itself )
Its easier to prove and convince a design as inappropriate if we know what alternatives were evaluated and why this design was choosen .
3)maintaning and versioning code
yes , we need all the versions of a program to support it well .
Its not just for some audit purpose , bugs lie subtly in code for years .
All your technical skills take you no where near the bug.
I mean , it takes insensible amount of time to figureout whats wrong .
(very possible when you are dealing with some proprietory tools and their custom commands and programming API's )
One thing that will help defitely is all your older versions , you can keep going back untill the point everything works fine .
Now all you need to do is to focus on what changed between those 2 versions .
Its a very simple thing , but i know CMM level 5 organizations loosing the code and reverse engineering the applications .
Its a very bad situation to land into , always try to avoid such a situation .
My experience with software applications range from Huge pile of scripts, Java Web applications,
Swing Client applications, Java based non-web Server-aplications etc ....
According to me , there are several relatively small decisions which go a long way in making any applications easily maintainable .
1)Seperation of business data and Configuration information .
I have been supporting an application which has a folder in unix , where there are number of PDF's stored .They are essentially business data .But part of the folder structure has a number of configuration files thrown in here and there .
Yes , thrown in literally .
There were more than 50 XML files and 20 property files distributed across some 30 folders .
Iam not saying it was not logical , it was organized logically .
But it made a maintence engineers and Users to doubt QA testing .
It becomes quite tough and complex to clone the application in QA .
Once people dont have confidence on testing , application is headed to bad times .
People give complex and nasty fixes , afraid to change anything more than what is required to fix the visible bug(Which more often tip of the iceberg) .
They spend hours making sure their change does not affect other scenarios , not think once if that scenario is currently working correctly or not .
They become too catious to do anything that remotely affect any other business user other than one who raised teh bug .I have seen scenareos where others users soon come in with the same problem and we endup giving the same nasty bug fix to each of them .Instead of doing a simple common design change .
So we end up 100 lines of code , 5 versions of the files and 5 UAT on a bug to hide away from users .
To fix it ,it takes 10 lines 1 version and 1 UAT to fix .
But since nobody really wants to approve , the entire process becomes self damaging .
Its a vicious circle , once something like this is done for say 5 years , application is becomes tough to maintain .Even the nasty bug fix carefully written not touch anything , ends breaking something .Bugs become more and more complex and often a bug represents a multiplicity of factors like wrong data , incorrect program logic , wrong design , network issue etc ....
Ability to confidently clone the application in a Test enviroinment .
High confidence on QA testing and subsequent approval are very important .
Else nobody is confident of touching the application , but software , like everything in the universe needs to well kept and compensated for the increase entropy
(read as "spend money on it" :-)) ) .
2)Seperation of Configuration information clearly into functionality specific configuration and enviroinment specific configuration .
This very important because , it adds to movability of the applications across servers , databases and middlewares .
What is Application of configuration ?
Typically , application mode , email template or list of people to email events .
Debug level and channel informations , and all other application settings .
What is Enviroinment configuration ?
Database instance name and encripted password , unix folder path , middleware connection parameters .
List seems small . but its easy to mix them up into a complete mess .
Example , a template file path in a property file having the full unix path ( a perfect mix of enviroinment and application configuration )
i.e.,
BlanketPurchareTemplate=/usr/awd10/a123app/config/pdfs/blanketpurchase.pdf
I know , its a simple example.
But imagine changing 15 configurations like this each time you have to replicate production.
You will want to avoid , and yes there will start all problems .
QA starts looking like a different program than production .
If enviroinment configuration is seperate , u can safely ignore them while Cloning .
Seperate is not just seperate file or table .There is no point in having 10 more files in 10 more folders , nooooo .
Group them together in 2 seperate folder structures , so any one can tar and move what they want , easily and confidently .
It should be kept in mind that other factors listed below are also equally important .
1)Consistent Code conventions and design conventions
Its harder to acheive in any long running applications , almost impossible if it was supported and enhanced by multiple vendors .
But we can live those issues most of the time :-) .
2)Documenting the reasons for a particular design(this more important than documenting the design itself )
Its easier to prove and convince a design as inappropriate if we know what alternatives were evaluated and why this design was choosen .
3)maintaning and versioning code
yes , we need all the versions of a program to support it well .
Its not just for some audit purpose , bugs lie subtly in code for years .
All your technical skills take you no where near the bug.
I mean , it takes insensible amount of time to figureout whats wrong .
(very possible when you are dealing with some proprietory tools and their custom commands and programming API's )
One thing that will help defitely is all your older versions , you can keep going back untill the point everything works fine .
Now all you need to do is to focus on what changed between those 2 versions .
Its a very simple thing , but i know CMM level 5 organizations loosing the code and reverse engineering the applications .
Its a very bad situation to land into , always try to avoid such a situation .
posted by Jagannathan at 10:56 AM
0 comments
