A developer on my team got assigned a problem that was supposed to be fixed a long time ago. This developer could not determine the cause of the problem. He told our managers that his system was corrupt. He could not run Visual Studio in debug mode. Thus he could not identify the code that was causing the problem.
This announcement caused all kinds of excitement. Our team lead told the developer to report to our offices (he works in a remote location). He showed up and could not find the rest of our team. So he found an office and started working. Luckily another guy in a remote location informed me the developer had arrived. I grabbed him and we met with our team lead.
Team leader was a bit frazzled. The management team must have beat him up a bit. He kept grilling me and the developer about when this bug could be fixed. I asked him why he was talking to me about it. He said that I was now going to be responsible for helping the developer get the bug fixed.
Luckily I had did the initial analysis on the issue. I knew exactly how long it would take. The team lead kept trying to dissect the analysis to figure out how we could ship it out quicker. I stuck to my guns. That there were two people involved did not cut the estimate in half. One guy could not debug the app. Luckily when we got to my desk, built a debug version of the application, it was a short while before we found exactly where the problem was occurring.
You need to be able to run the application in debug mode. There is no substitute for this. If you cannot debug the main applicaiton, you must treat this as an emergency and get it fixed. Otherwise you will be of little use to a maintenance team. Even the managers can see that.
Performance Tricks in Other Databases - I have been working exclusively with the Oracle database for over 15 years. Now I have jumped to a project that uses the Greenplum database. This is a dis...