Manage errors among Dev Teams

Question

We are going through some very interesting debates as to how we should manage errors/issues in our IT department. I would really like to hear what others say about how they manage application/feed, etc generated errors.

We are being pushed to put everything into BPEL (Business Process Execution Language) so that the non devs can see what is going on and not have to look into the code when an issue arises. The problem is...(as most of you I am sure know) that the code is only part of the eqution. You also have to be familiar with the process/flow to be able to really do something about an error. Putting in a "fix" without the full understanding could have large ramifications.

Anyways would love to hear how others deal with these types of issues...(Providing proper visibility to code/app generated errors).

Thanks!

S

Answer 1

There are a few companies implementing "social" ideas and very much like stack**overflow** here implement a team &| individual scoring system for bug and error fixing, though one must question if said bugs would be introduced for the sole purpose of fixing them.

Answer 2

The loyal thing to do would be to try FogBugz, no?

Answer 3

I'd recommend staying away from anything complicated (such as BPEL) and just purchasing a 3rd party software package that can be tweaked, if need be. So, yes, FogBugz is one example that could work. There are others: AxoSoft OnTime, Rally's RallyDev, etc...

Especially since you are a small shop, I'd avoid like a plague spending time on issues you mentioned, and focusing instead on your core business.

As far as visibility for various logs, etc for management ... create a web page with links to these. Done. Don't waste too much of your time on stuff like this.

Answer 4

Be very careful here, there may be unstated agendas at work.

Faced with the problem of making our error handling process more open, we implemented Bugzilla on a public intranet server, but carefully restricted who could post and who could change bug states etc. That worked pretty well: faced with having to provide repro cases and evidence, people who had been voluble before suddenly got a bad case of reticence. Our bug reports increased in quality as a result. Better reports == more fixes. Everybody wins.

I'd stay a country mile away from stuff like BPEL. Not least because if your non-devs can't read code, I don't see how staring at something like a Nassi-Shneiderman diagram is going to help them. Formalism implies rigor, and non-dev people generally aren't very good at the whole rigor thing.

If the intent is to publicise how your system works, as opposed to how it fails, and you need to produce something that non-devs can understand, then a good educational solution is a publicly available intranet wiki. Just understand in advance how hard it can be to get people to knuckle down and write the content. Ours stalled pretty quickly, sadly.

Last but not least, make very sure here that someone in management isn't trying to use this process to force metrics/KPIs in via the back door. That metrics nonsense can destroy a functioning department in a startlingly short space of time.