Recently the customers informed us that their most important problem had not been fixed. My manager called me to appease the customer. I took a peek in the production environment. Yes the data was messed up. I guess the last fix did not do the job.
My boss was worried that the customer was going to continually think that the problem was unresolved. So he had me meet with the customer to define and document exactly what they wanted. I speak their language. So it was clear to me. I just wrote down all the unwritten and unsaid assumptions that I comprehended.
In the end, I came up with a 4 page document. We met to ensure this document was correct and complete. My boss asked that the customer and I agree on any unusual boundary cases. So I discussed and documented what my data correction script would do if it ran into unexpected scenarios. The result was still 4 pages of documentation.
Now most of this documentation was just regurgitating the basic information that I and the customer know. The reason for this document was that none of the managers or executives know the basics. The testers for the most part do not have a strong understanding of the basics either. I was reminded of this as we entered testing of my script. However they did get a solid tester on the scene. He just needed to learn some of the business rules before he could make heads or tails of the testing required. Our team loaned him a developer to assist him, but this guy needed more help to get through all his tests. Luckily this was a high priority task. So I was directed to make time for it.
Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...