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…

How long does your program live? Part 1

Have you considered the lifespan of your programs? You might have thought of scaling issues, security concerns and hardware settings. What if your program is still used 5 years down the road? 10 years? 20? Will it still work?

I had the occasion to work on a system. The thing was, it dealt with financial years. In case you’re wondering, a financial year (typically?) starts on April to the following March. So financial year 2009/2010 starts from April 2009 to March 2010. Calendar years are the “normal” ones, starting from January to December of that year.

Where was I? Oh right, the system with the financial years. So the Unix shell script that runs as an interface displayed up to the latest 5 financial years. There’s an accompanying set of C programs, as well as a corresponding set of database tables. It’s not well thought of, but it’s the best under the circumstances.

What happened was, every time a new financial year arrived, a new set of database tables was created (appropriately named of course). And a new set of C programs copied and pasted and edited (to insert, update and delete from the new database tables). And new lines of code added to that Unix shell script. This happens in late February and March, to prepare for the imminent arrival of April (April has more clout than August, even though August is well respected…)

So I did that for one year. Then the next year arrived, and I found myself with 7 financial years worth of program options, but only needed to display 5. The manager and senior colleague were already set to go for the path of least resistance: doing whatever worked last year. I decided otherwise.

I went through the code for the shell scripts, database scripts, stored procedures and C programs. The code were all flexible in that only the financial year portion was changed. So I told them that I’m going to change all the code so that the code took in the financial year as a parameter, or that it automatically calculated the correct financial years. The manager gave me the go ahead, and I went to work quickly, for it was February, and it’s unknown if I could get it to work in time.

There were some problems, and I’ll tell you about them in the 2nd part of this exciting mini-series…