The macro

It was a long day and it was looking like it would be getting even longer. To release my program to production would require a number signatures before I could even begin. In a pure development environment I was used to having a list of changes as long as my arm that I was expected to work on as soon as possible but as a consultant things were a bit different. You cannot simply make changes to a production treasury system because you didn’t like the style of some of the code or because you would like to test out a new technique. The amount of paperwork that is required for even the smallest change is unbelievable but after enough people signed off on it, I was permitted to begin a change that the users wanted, nay, needed for future expansion.

It was late and I was hoping to get in some development done without any interruptions. It turned out that not everyone had left. It seems that Pitr was also on a mission and also enjoyed the quiet when most people had left. Just a bit of background, the production downtimes are the third Wednesday every two months. They are not guaranteed to occur but more often than not some fix does need to be released. The year is 2013 and the production downtime plan has been published for the remainder of this year and next but it seems that isn’t good enough for the accounting team. It seems that they wanted to know what the plan will be for 2015, yup two years in advance.

I can understand a bit of planning but perhaps it wasn’t quite clear that these downtimes are for only two hours and they are not even guaranteed. Well, Pitr had a solution. His idea was rather than answer these types of questions piecemeal he spent most of his working day writing a macro to generate the list of dates.

Well, I cannot say how much of his time it did indeed take to create the macro, but I can tell you how much of my time it took. I was in the middle of debugging my program when Pitr came to show off his programming prowess. He didn’t take any hints that he was preventing me from finishing my work. I spent a good 45 minutes listening to the rational behind creating a macro to generate a list of downtimes for the next 22 years.

It is not clear if the treasury will even continue to use the software for that entire period, but we now can find out when any downtime is on any environment from November 1st 2011 until December 28th 2033.

Even though I would have originally thought that this is the end of this story it is not. If there is any unexpected change to this plan for any of the seven environments over next 22 years, then the downtime list will need to be manually amended with either the unplanned cancellation or the unplanned downtime. The only thing that I was certain of was I was happy that Pitr wasn’t my employee.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close