How many tickets do you close in a day?

dalecosp

I'm curious if you have an "issue tracker/bug tracker" or similar system, and, if so, how many issues do you "fix" or "resolve" per day, or per week?

(I'm not under any particular pressure to ask this, (I have one but no one is questioning my performance AFAICT), so there's nothing riding on your answer, unless your company expects $x tickets a week and you're faking it and your boss reads PHPBuilder and knows who you are ... 😃 )

FWIW, today is Wednesday and I show that I've handled 5 issues so far this week, but only 4 of them are "resolved". I also show 56 issues that are NOT resolved, although several of those are usually "DO NOT FIX" or "DO NOT FIX YET", or "NOT FIXABLE / NOT REAL ISSUE".

And, of course, there seem to always be issues that get fixed without getting INTO the tracker in the 1st place. But maybe that's just 'cause we're a really small shop...

NogDog

While we do use a ticketing system, most of my work is not fixing localized bugs, but rather adding features, performance improvements, or new/changed configurations for new/changed clients, along with reegineering the product I work on under a new language/framework (because why not?). Therefore, if I close a ticket a day, that's probably about normal.

Derokorian

While I don't spend all day every day working on bugs. I do tend to close 2 or 3 tickets a day of normal work. For bugs tho, it depends, I can close as many as 15 in a day or 0, it really depends on the bug(s) and how many customers know about it (yeah, we've had some bugs sitting around for 2+ years because they only affect one customer who doesn't pay us much).

dalecosp

Thanks for the replies! I thought this might be a good topic of discussion here.

I think I'm in a similar situation; "projects" sometimes get thrown into the bug system, but more often than not, just as a generalized entry, or not at all. If someone comes and says "we need a new landing page for this event/product", it might not get an entry, because I assume it'll be done before I can forget anything much about it 😉

Sometimes larger projects will have an entry or two. So it's an "issue tracker", more than a bug tracker, I guess. Listening to people who I assume work at $bigger_companies, I often assume that there's one guy (a PM?) who mostly sits around talking to everyone and making sure that every detail gets into the system and assigned to a developer ... but maybe that's not any of our shops.

Here, I set up the tracker and 99.8% of all the entries are mine. I hesitate to specify just how many I 'fix' in a day; one to three seems average if I'm lucky but sometimes I get all crazy and do a bunch (browsing in reverse chronological order, it looks like I touched 16 one day last summer but 4 of them still aren't resolved....

cluelessPHP

Do my own mistakes count? If so far too many but compared to you guys I know next to nothing :p

dalecosp

NogDog;11054411 wrote:
along with reegineering the product I work on under a new language/framework (because why not?).

"Why not?" around here is "we don't have time to chase rainbows because we need you to do $x RIGHT NOW..." :eek:

NogDog

Well, one of the why's is because we've gone from being a mostly PHP shop (on assorted frameworks) to a mostly Ruby on Rails shop. The other why is because the app has accumulated over 4 years' worth of "spaghetti" built on top of a custom framework, with me being almost the only one left who can untangle it. 😉

dalecosp

NogDog;11054451 wrote:
Well, one of the why's is because we've gone from being a mostly PHP shop (on assorted frameworks) to a mostly Ruby on Rails shop.

Hmm, is that "by design" in that the people upstairs thinks Ruby is the way to go, or is it more about "the talented people we liked in the interviews preferred Ruby"? IOW, conscious choice, or more of a general evolution?

The other why is because the app has accumulated over 4 years' worth of "spaghetti" built on top of a custom framework, with me being almost the only one left who can untangle it. 😉

Sometimes I think I'm the only one who can do anything here. :rolleyes:

And send me some good spaghetti! 😛 I'm kind of on a similar project ATM ... replacing a closed-source layer ... tough job, but if I can get it done by summer I save the company $$$ ...

NogDog

dalecosp;11054453 wrote:
Hmm, is that "by design" in that the people upstairs thinks Ruby is the way to go, or is it more about "the talented people we liked in the interviews preferred Ruby"? IOW, conscious choice, or more of a general evolution?

I think it was a combination of a grass-roots movement by a small group of devs with influence along with some engineering management types who were brought it. I.e., nobody asked me. 😉

Sometimes I think I'm the only one who can do anything here. :rolleyes:

And send me some good spaghetti! 😛 I'm kind of on a similar project ATM ... replacing a closed-source layer ... tough job, but if I can get it done by summer I save the company $$$ ...

I've got some so-called object-oriented code with individual methods that are several hundred lines long: would that do? 🙂

Bonesnap

Generally speaking, we don't track bugs or issues. At least not formally or officially; however, since around December I have been teamed up with another coworker and we're basically exclusively doing work for a one big client, and we have had the opportunity to start using Git (yeah, we don't use version control here either). With that we use Bitbucket to have a "central" repository and we utilize its issue tracker. I think over the lifetime of the application (which actually just launched last night) we have had ~150 issues. Some days I'll close none, but other days I might close 5 or more. It really depends how much testing the client does and reports back.

Fortunately my coworker and I have communicated the importance of the issue tracker and how much it's helped us to management and they're considering/figuring out a way for everyone to use it. We looked into GitLab but it only runs on Linux, which we are not, though apparently there's Gitbucket but we haven't had time to investigate it yet.