I saw a new high priority customer trouble ticket come in. It got assigned to a junior developer. Our team lead said he would help out as well. Then the test team shared some of their findings. I was hoping all was going well. Then I got the dreaded invite to the conference call.
Reluctantly I dialed in. The boss asked whether this problem was related to any other fixes we recently deployed. I tried to stay out of this. People were trying to recall what changes went in to fix what problems. They were also trying to determine whether any of those changes were incomplete.
Finally I could not take it any more. I said we really needed to get back on track. Somebody should find out whether what the customer is reporting is actually happening. Then they should find out why and fix it. After all that we can then investigate how such a problem slipped by. Eventually the boss and the team lead agreed. Then all the developers started saying they were unable to work this weekend. That's when I knew our conference call had become broke down again. Luckily I was able to switch to a higher priority task before conference call number 2 started up on this problem.
Maintenance is not really that hard. You talk with users to find out what they are experiencing. Then find out what they are expecting. Determine if their expectations are valid. See if you can make the problem happen. Then code a fix to make the problem go away. If you are mature, go a little further to find out how the problem can be resolved. Anything beyond these simple steps are going to be a waste of time. Seriously.
Cisco Packet Tracer - I downloaded this software for free from Cisco. From the name "Packet Tracer", you would think this is some type of packet capture/analysis tool similar t...