Financial reports must be untouched by human hands

People handling billing or financial data are usually very uptight. Especially when it comes to numbers. If you thought mathematicians, statisticians or economists were protective of their numerical figures, go talk to someone who works in the financial department.

PI is an elegant number. It goes to about 3.14159265, and describes the ratio of the circumference of a circle to its diameter. It doesn’t mean much to a finance person though.

But the bits have mercy if their report shows that there’s a $3.14 missing.

Sometimes, in the course of my work, I get requests to dump data from the database. Well, more like generating ad-hoc reports based on whatever was needed. Excel seems to be the preferred output format, since it displays all the data in nice little columns and rows. And let’s face it, the user is probably more skilled in Excel macros and functions than you and I are. Let them do their little calculations and predictions and pie charts, I say.

But noooo… Finance people will have none of that.

“I cannot manipulate data.” was the usual answer.

Wait, when I churned out those data, wasn’t I manipulating data, of sorts? I was doing SUMs, GROUP BYs and ORDER BYs with the database queries. If the user wanted a sum over that particular column, and I didn’t provide it, just use the inbuilt Excel sum function.

“Oh no, I cannot manipulate data.”

Apparently, whatever financial reports must be completely generated by the computer. All financial reports must be untouched by human hands. Let’s hope you got that algorithm right. Wait, aren’t you human? Would that mean the reports went through human hands?

If not using the database, please disconnect

I’m maintaining some Windows programs created by the PowerBuilder software. The original developer didn’t plan for the programs to be used by many people. So the instant one of the programs was run, a database connection to the Sybase database was opened. And left there.

As more programs were created in this manner (and added to the suite of programs my team is in charge of), the number of total users also increased. Since the connections were held in place, table locks between users became a real problem, because a user could be done with an operation, but still hold onto the table. This also meant the database became clogged up with connections, usually non-active.

The better solution is to open the connection when you’re going to do any database operation, and then close it once you’re done. But the original programs were developed like eons ago. If I understand it correctly, client programs back then assumed they had total control over the database. Contrast that with the web applications of today, and let me just say that, I have my work cut out for me…

I decided to write something on this after reading Raymond’s article on cookie licking. So if you’re not using any database functions, please disconnect.

FAHTR aka Free And Happen To Remember

The following completely fake conversation was inspired by an actual conversation with an internal company user.

User: The web application doesn’t let me do XYZ. I can’t download ABC data for customer PQR.
Me: Well, your customer database don’t have JKL. The code changes will take some time.

User: So how long will it take?
Me: It’s not urgent, right?

User: Well…
Me: Then I’ll do it on a FAHTR basis.

User: What father?
Me: FAHTR. It means I’ll do it when I’m free and I happen to remember to do it.