Problem Diagnosis: You Will Never Think As Stupid As Some Users

September 29th, 2010

One of my clients recently came back to me with a problem. I had built an invoice system that let their users generate an invoice and go to PayPal to pay it. However, it was discovered that some users had invoice numbers that they had made payments for, but that had no corresponding entries in the database.

So, I immediately dug into the problem with my client, and we worked together to idiot-proof the system. Over the course of two days, we changed the invoice system so that you could not go back and modify an invoice after you had been sent to PayPal. I added an index to track the invoice status, to facilitate this, and we fixed a few holes in the process if a user just closed their browser at any point. Overall, I think we had fixed almost 10 different small and large problems with the process that we thought might have led to this issue with disappearing invoices.

Satisfied with the work we did, my client went happily on his way with this upgraded system. It took about two days for them to have a problem with invoices again, and for me to be contacted about this. So, we reviewed the work done, and concluded that there was nothing we could think of that we had not already fixed. I added a simple piece of code to log the contents of every single invoice every single time it was generated into the database, and we contacted the web host to get MySQL query logging turned on, in the hopes that we would be able to figure out something by doing this. Frustrated but hopeful, we left this in place, and went on our way.

The next day, we had another incident with a missing invoice. I started digging into the background of the invoice number, and pulled the records on it from the log. It was created, but as far as the system was concerned, it was empty. Digging a little more, we verified that was indeed the fact. The MySQL queries for that invoice number turned up several inserts, and sure enough, there were no inserts for actual invoice items. We pondered back and forth for a minute, but were stumped as to why there was a paid amount for that invoice number, but no value in our systems. Finally, my client figured it out. He went through the invoice process, and went on to PayPal with a zero dollar invoice.

Turns out, you can enter your own amount for any invoice number that goes to PayPal with a submitted value of $0.

The clients customers had gone through the process, and when presented with a screen of items to select from, chose nothing. These users then went on their way, clicking through the invoice verification screen, which showed them that they had selected no items, and a Grand Total amount of $0. Happy with this invoice, they continued on to PayPal, where they were presented with a box to enter their own cost, which they entered with no question as to why they had to. They all managed to enter the correct costs for what they wanted, and paid. Come time to verify these payment emails that the client was receiving from PayPal, the client went looking for a matching number in this system, only to be baffled that there was none.

I quickly added a check to disable the payment button if their invoice was empty, so that the customers have to select something to pay for before they can go to pay. And now, the client is happy.

You will never be able to think as stupidly as some users.

Eating Your Own Dog Food

September 14th, 2010

Some background. I have a simple time tracker that I built a few months ago. It lets me log start and end times and a message to describe the work I did during that time. It was a simple journaling tool, but limited to one client per copy.

I’ve gotten tired of working that way, so I am currently developing a v2 on top of my new framework. It’s going to have proper time tracking, client management, and all sorts of other goodies.

This is defiantly a lesson in eating your own dog food however. I have encountered so many small and large bugs in many of the pieces of code I have developed. Still, a lot of fixes result in this. The most interesting though is this is the first time I am using my ACL class in a full project. I had done some rudimentary unit tests in the past for this project, but it was after the fact, and only intended to catch basic problems. It is so useful to have a project to test it with, and this work is uncovering so many things I didn’t even consider when I first built ACL. I’d worked on that class for a year and a half, but there are still many things that I need to add it seems.

For those of you that are interested, I will be releasing ACL in the near future, as it is a useful piece of code that will make your brain explode. So my next project is going to be documentation as well.

WordPress - Entries (RSS) and Comments (RSS) - © 2011 Ben Dauphinee