Tuesday, June 15, 2010

How to hide problems in software behind business rules (and what happens afterwards). Case Study

All started at the end of May 2010 when I found a strange bug (from my point of view) from self-service system of one of Estonian biggest banks.

I tried to pay my taxes to local Tax and Customs Board when I noticed the money wasn't transfered during the time I expected (later I found out took 2 banking days to arrive). So I started checking what's going on. I found that payments made after 23:00 local time got timestamp 24 hours to the future. For example payment order for payment made 25.05.2010 23:40 got timestamp 26.05.2010 23:40. So I enquired from bank. I got nice reply (translating and shorting the email):

"Thank you for your letter. According to our terms and conditions of account management we quarantee in-bank transfer within 1 hour though usually it takes less. So the money is transfered to another account but has timestamp for the next day of real transfer".

So I noted out that money wasn't transfered during next work day. After that I got reply pointing that "It is not a bug. According to our terms and conditions payments forwarded after 10 p.m. shall be excecuted immediatley but amount shall be expressed in the account statement of the customer under transactions of the following day".

Okey I thought. Bank says it's not a bug. So did I really make mistake this time... Doesn't feel right...

I started enquiring from Tax and Customs Board. They replied that current amount was logged into their system until 2 days later in the morning and according to their info the transfer didn't came through immediatly. If I tried to make payment during day the transfer went through on the same day so it couldn't have been issue from their side.

I forwarded current message to the bank but their reply didn't change much. They still refer to terms and conditions.

So I made my conclusion from information I posessed - Due to the fact that their banking day doesn't match astronomical day they couldn't fix it to make it match properly and applied business rule for allowing this bug to remain (now called a feature). However now that 3rd party systems are getting data from their system something goes wrong due to this feature. My best guess is that due to the wrong timestamp the information isn't forwarded at correct time, but instead it is forwarded in the time marked in the payment order. Hopefully I'll find out the real reason soon and can close this subject in my mind.

However I must admit. Nice idea to use business processes and rules to change bug to a feature. Have seen it before in other systems and working pretty well. But it might come back to haunt the system if another system might need correct value instead of value inserted by the feature.

PS. I also found mistake from Tax and Customs Board's system while looking for this specific mistake. It's getting slowly out of hand... Finding bugs from almost any system I use...

No comments:

Post a Comment