A manager on my project wanted to know how some things worked in one of our applications. They needed to speak with a customer. So this information needed to be very accurate. I kind of knew how the application worked. However I did not know all the details for sure. We have a lot of documentation that describes the most intricate details of the applications. Some of this documentation is old. My instinct told me not to trust the documentation. I had no other alternative than to reverse engineer the application behavior through a series of tests.
I spent a lot of time conducting different scenarios to test. It was good that I had some idea on how the application worked. That way I could choose tests where I was not sure of the results. I could also infer a lot from just a few tests results. This was not an exhaustive search of all the possibilities. That would have taken far too long. It took about half a day to get the data I needed.
This technique may not work for everybody. You have to make sure you really get a firm understanding of what is going on behind the scenes. However I trust this more than consulting some documentation or even reviewing the source code. In my experience, it is best to trust nothing. I know that sounds a bit like the X Files. But it is the safest approach.
Now I can say with confidence how the application behaves for some certain behavior. If anybody wants to challenge me, I can ask them where they got their information. Is that just the way it is supposed to be? Did they hear it from somebody a long time ago? Did they read this in some document? I can top all of that. I just tested the actual application out. You can’t beat that kind of experience.
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...