Troubleshooting and developing... the balance between

[pzmgmb]

Just Curious...

I work in a company that has a small IT department and I was just wondering how other developers manage troubleshooting on existing apps and development work on other ones.

To me its one of those big thorns, you develop and deploy an application and then troubleshooting issues trickle in... Sometimes they are an easy fix... and sometimes it takes time to reearch why it happened or what caused it... Of course you plan, develop, and test to ensure that these issues are kept to a minimum, but when the number of applications you are supporting increases... a few issues from a few apps become a big distraction and steal precious development time.

I was just wondering what strategies you all use to balance your troubleshooting time and development time.

Thanks

 

[DoubleD]

Prioritization becomes critical as you begin to support more apps. If you're not already using some form of issue tracking software, I suggest you start. It doesn't have to be anything fancy, a simple access database can do the job.

Issue Tracking will help with the following:
1. Identify what maintenance work you have on your plate.
2. Allow you to define the criticality of each issue. (Not every issue needs to be fixed today. )
3. Set target completion dates based on criticality.
4. Measure whether you are accomplishing your target dates, or whether you need to adjust them.
5. Communicate your target completion date to the users.
6. Ability to be proactive in communicating with your users when you can't make a deadline.
7. Ability to qualify the need for additional personnel.

I am what I am based on the decisions I have made.

DoubleD

 

[chiph]

5a. Communicate your target completion date to your manager.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Onyxpurr]

You may want to work with your manager to develop certain categories for self-prioritization of issues/projects.

Usually such categories will be dependent on how the issue affects business, users, etc.

For example, if you have an issue that comes in that affects the entire company and they're ability to do business, that would be a priority A1. As opposed to an issue that affects the entire company, but does not affect business (e.g. intranet webpage with new employees), that may be allocated a priority of C4.

 

[zemp]

I agree with tracking and prioritizing the issues and new development. Communicating target completion dates, which can change quickly, is a must. I always try to give myself a good time cushion when giving completion dates to clients.

One thing I try to do is to keep project work together. In other words when I get my head wrapped around a project I like to only work on it for a few days at least. I find it easier than flipping back and forth between projects every day. As a result I usually don't deal with project troubleshooting until I feel there is a few days worth of work.

Of course if something is deemed critical that is all out the window, sigh...

And when the flipping gets too much its time for tek-tips. You'll notice I'm here a lot.

zemp

 

[willir]

pzmgmb

The prvious posts deal with prioritization, time management and communication.

develop and deploy an application and then troubleshooting issues trickle in...

Do you deploy your applications to more than one vender or is just one vender?

The reason I ask is that if you deploy to multiple parties, you will have "updates", and you have to make sure the updates is applied across the board. For example, you dont want to deploy an upgrade that recreates a problem already fixed...

A) Have you application log the errors. You would be surprized at what is NOT reported by the end user. It also helps you capture more info on the errors than reported by the end user. If the log file is written external to the application as a text file, you review the log file externally. You should have a way of clearing the log file, and ensure it does not fill up a file system.
B) Use a tracking system to track the problems, ownership and resolution.
C) All updates applied for the customer applications should also be applied to your proposed "update" database.

Review the log files periodically to a be preemptive if possible. For example, have a process of automatically grabbing the log files for review.

Use portable code. This really speeds up development where code can be copied from app and pasted into another app.

Adopt coding stadards that includs documentating the code.

 

[davidwendelken]

You also need to categorize the source of the problems that you are troubleshooting.

Was it a failure in installation, testing, coding techniques, or analysis?

It makes a big difference where the problem originated, because the actions you will have to take to change things for the better will be very different.




David Wendelken

http://www.casetech.net