Our customer has a system acceptance test team. They reported a problem they found in our system. Our internal test team could not figure out what they were talking about. Unfortunately the responsibility to test our fix went to the newest guy on our internal test team. This guy had no chance of figuring out what to do. He sent me an email and left me a voice mail asking for help. All he could figure out was that the DBA Team had given them something to test. And he was truly clueless as for what to do next.I don’t want to spend my life on this project doing other peoples jobs. So I knew I should not just give the tester all the answers. I recommended he start at the beginning and see if he could understand and duplicate the problem that the system acceptance team found. He said he tried running the applications, but could not see where they were finding any discrepancies. I proceeded to spend the next hour or two going over how the system works, how it is supposed to work, and how he could experience the problem in his own environment.
Previously I had assigned this problem to the DBA Team. Their yearly process had deleted some data that was required to be kept around for a couple years. The DBA Team lead told me he was never informed of that requirement. I responded that this was his official notification. As he got into working the solution for the problem, he realized that the fix to restore the data was a programming nightmare. I would have loved to have written a bunch of PL/SQL code to do the work. However I was tied up with other duties.
Later the DBA Team lead came up with a solution that would make his job easier. However it would require adding some new tables to the schema, and also some changes on the application development side of the house. He asked me to negotiate the new tables with the data architect on the project. So I called her up and let her know the situation, and where we wanted to go with the solution. She had some suggestions but was quite flexible. The I came in and wrote some new code in one of our PL/SQL packages. That was really fun. I updated a couple database triggers, and gave the code to the DBA to promote.
Here is what I have learned from this problem. You really need to know the business of the system to understand the complex issues. Most of the work in resolving system problems at this level does not involve sitting down and writing code. I have some other lessons learned about database design. However I will save those for a future post.
