Nicky came with me to work this past Wednesday for “Take your kid to work day”. Not only did he see first hand what I do, he even helped me do it.

I showed him the “Database Explorer” software that I’m helping to develop for the next version of SAP HANA. It allows you, among many other things, to execute arbitrary SQL statements against any HANA database. But before he would have any idea what that was good for, I had to tell him what a database was. I simplified it to: a database is a collection of data stored in tables, where a table has a bunch of columns and each column has a type (i.e. text, numbers, dates, etc.). As an example, we created a table called “person”, with columns like “name”, “height”, “weight”, and “birthdate”. I inserted a row for Nicky and one for me.

Then I showed him how we can use the SELECT statement to get the data back. So “select * from person” shows both of us, with our names, heights, weights, and… incorrect birthdates. Each date was off by one day. Hmmm… that’s weird. Perhaps I made a typo on one of them, but not likely both. I updated a row and double-checked the birthdate but when I retrieved the data again, it was still wrong. OK, well, guess what Nick? We get to look through the code, find the error, and fix it. This is what I do.

I knew where the data retrieval code was, so Nicky and I looked it up and found where we get the data from the database and format it for display. I added some code to print out the value we retrieved and found that we were actually retrieving the correct date. This meant that it had nothing to do with the insertion process, and that the database itself wasn’t involved. Then I added a line that displayed the value again after we formatted it and found that it was wrong. So it was definitely our formatting code that was to blame.

This is written in Javascript, and we were creating a Date object from the original value. We looked up what the Date constructor expects, and found that the format we were passing in was incorrect. Then we parsed the year, month, and day out of the date and used those directly to create the Date object. We fired it up again, and presto, it worked. High five, Nick.

Our next task was to write a barrier test. We have a suite of automated tests that run and must pass before anyone is allowed to make any changes to any piece of code. This is to make sure that nobody ever makes a change in the future that causes existing functionality to stop working. I knew there was a file that contained tests for many different data types, so I loaded that up to add a test for dates. Oddly, I found that there was one already there, but commented out. Then I read the comment, which stated that the test was failing but the author didn’t know why, so he was temporarily disabling it until later when he had some time to figure it out. The comment was signed “gperrow”.

I enabled the test, corrected one typo, and presto, we have a fixed bug and a barrier test. High five, Nick.

Nick said that between the bug squashing (he prefers that term to “debugging”) and playing with the Arduino and 3D printer in the morning, he had a really fun day, as did I.