How long does your program live? Part 2

Ok, it’s been a long time since part 1. I apologise. Frankly speaking, I can’t remember what I wanted to talk about… After much thinking and recalling and tea drinking, it came back to me.

So, problems. I was talking about a family of programs living way longer than its creators at my company in part 1. And that program dealt with financial years. Here’s the thing. Financial years were represented in “pairs” of years and in 2 digit form. Thus we have, say, financial year 09/10, representing April 2009 till March 2010. The previous financial year would be 08/09, representing April 2008 till March 2009.

My problem then was that, this family of programs lived everywhere. There were “09/10” notations in the database tables and views, in the stored procedures, in the Unix shell scripts, and in the C programs. I had a lot of work cut out for me.

My first goal was to get similar C programs to be replaced by just 1 program. Oh you didn’t know? There were programs like foo0809.c, foo0708.c, foo0607.c, and there’s bar0809.c, bar0708.c, bar0607.c … you get the picture. So I wrote a fooXXXX.c to replace all the foo programs, and corresponding C programs for the rest. It was basically a careful search-and-replace operation, together with an additional parameter for the financial year in the main() arguments.

Sometimes, a program generalised to take in parameters is better than several programs doing the same thing but on different database tables. I guess the original programmers didn’t plan enough about the whole structure of the system working together.

Then I did the search-and-replace operation for the shell scripts too. Some of the shell scripts also creates views and database tables for the new financial year, so I had to take care of that. Then came the really nightmarish task of tackling the user interface run entirely by a shell script…

The UI consisted of carefully aligned printed text, and choice options. Much like the choose your own adventure computer games of yore, where you were given a description of the place you’re at, and some choices you could do. This one looked something like:

===================================
     Welcome to Program Foo!

Please choose an option:
1) Jump up and shout
2) Do a funny dance
3) Eat a sandwich
4) Point your finger at your most
   hated enemy, and cry
   "Behold the wrath of my fury!"
   fully expecting some sort of
   lightning or fire to erupt on
   the body of said hated enemy.
5) Exit program

Enter your choice :
===================================

The fun part of it was that there were different variations of presenting the financial year. Some parts used “fy 09/10”, some used “fy0910”, some used “fy 2009/2010”. Know also that I worked with it where pre-2000 years existed, and some interesting programming calculations were called for… most notable was 1999/2000.

I had to keep, say 2009 in a variable. For the “current” financial year, I would add 1 to it to get 2010, then do substrings on them to get the last two digits and print them to get 0910. (or 09/10 depending). The requirement were such that the latest 5 financial years were to be displayed, so I decided to just precalculate the 5 years on immediately loading the script.

Then there was the special condition. Because the programs dealt with data from the previous month, when executing the main UI script in April 2009, it’s not considered the financial year 2009/2010. It’s still 2008/2009. I only knew this because that senior developer (previously mentioned in part 1) said the UI was one month “early”.

So finally, I was done. The main UI script has options which run either another script or C program. Those child scripts or C programs then ran against the database tables. And all of them used the correct financial years.

That’s it. I’m fairly sure I had a third part in mind for this series… Let me go search my memories…