A peer team had been changing the way they saved data. After all the work was done, we discovered that much of the data we needed from their system was no longer available. These tables are very wide reference data tables with hundreds of columns each. They said to write a bug report for each missing field.

I wrote a single bug ticket, and attached of a list of the old table/column fields that disappeared.

A day later, I notice that 794 child bugs had been created; one for each missing column.

Why?

Because they're separate issues.

Ok, whatever; it makes them look bad, not us.

Unfortunately for the other team, the parent company recently started using dashboards to see (among other things) how many problems occurred with each system - under the guise of quality control.

At the next high level meeting, someone noticed a massive spike in bug reports for the peer system, and the manager was forced to dance.

Ya gotta love Karma.

snoofle:

dance

...their way out the door? Not familiar with the jargon here.

toon:

snoofle:

dance

...their way out the door? Not familiar with the jargon here.

I think it's more the dance one does in cowboy movies when someone is shooting at your feet (with the questions being metaphorical bullets.)

That's the image that came to my mind anyway.

Sounds like they undercounted issues to me:

"Bit number 0 in byte number 0 has the incorrect value, causing undesired behavior."

"Bit number 1 in byte number 0 has the incorrect value, causing undesired behavior."

etc.

(You could probably go down to subatomic particles if you really wanted.)

Obviously, they are being rated by how many bugs fixed.

We have moved on from being rated by lines of code. Cool.

Rick:

Obviously, they are being rated by how many bugs fixed.

That's what I thought at first. But then, look at it from management's point of view. I mean, the shit hit the fan here because the customer noticed a peak in the number of bugs; surely management aren't too stupid to realize that higher numbers of bugs, means bad design and/or bad coding? I, for one, know that customers aren't. Any moron can see that if you have to fix bugs a lot, then you are spending time (which is, of course, money) on what should not even exist in the first place. Of course, there are going to be bugs and they're going to need fixing. But the more bugs your team fixed, the worse your team is. And finally, of course, there's the question of who's going to pay for all that bug fixing. Will management be thrilled beyond human comprehension, at the overhead costs of having over seven hundred bug reports instead of just one? I don't think so.

So I kind of doubt that even where Snoofle works, people are being rated by the number of bugs fixed.

I did something like this on one of my projects.  It was a form processing project and had almost 40 forms.  I found a bug that affected each of the 40 forms, but the issue was in the form's specific files.  It was nearing the start of production and we had our open ticket list down to almost nothing, which we wanted right before start of production since we were expecting a slew.  I opened a ticket for each form, rather than just one that fixed all of them, even though it was only a one line fix for each form.  I did this since it could result in a cross form patch dependency issue if one form had an issue and required a rollback and thus could get messy.  But it was funny to go from only having 10 outstanding tickets to 50 right before start of production.  Scared the hell out of the higher ups.  My lead told me not to do that again.

toon:

Rick:

Obviously, they are being rated by how many bugs fixed.

That's what I thought at first. But then, look at it from management's point of view. I mean, the shit hit the fan here because the customer noticed a peak in the number of bugs; surely management aren't too stupid to realize that higher numbers of bugs, means bad design and/or bad coding? I, for one, know that customers aren't. Any moron can see that if you have to fix bugs a lot, then you are spending time (which is, of course, money) on what should not even exist in the first place. Of course, there are going to be bugs and they're going to need fixing. But the more bugs your team fixed, the worse your team is. And finally, of course, there's the question of who's going to pay for all that bug fixing. Will management be thrilled beyond human comprehension, at the overhead costs of having over seven hundred bug reports instead of just one? I don't think so.

So I kind of doubt that even where Snoofle works, people are being rated by the number of bugs fixed.

You have not spent enough time perusing TDWTF.

 

Anketam:

I did something like this on one of my projects.  It was a form processing project and had almost 40 forms.  I found a bug that affected each of the 40 forms, but the issue was in the form's specific files.  It was nearing the start of production and we had our open ticket list down to almost nothing, which we wanted right before start of production since we were expecting a slew.  I opened a ticket for each form, rather than just one that fixed all of them, even though it was only a one line fix for each form.  I did this since it could result in a cross form patch dependency issue if one form had an issue and required a rollback and thus could get messy.  But it was funny to go from only having 10 outstanding tickets to 50 right before start of production.  Scared the hell out of the higher ups.  My lead told me not to do that again.

I once wrote an in-house language for accountants to generate their own budget reports, providing them with a free-form syntax within the old card-based editor.  Following the documentation standards in place that called for a page defining every fixed-length field and its use, I had the choice of defining either one field of eighty characters, or eighty separate fields of one character each with a lot of "usage depends upon the data values found in these other seventy-nine fields".

I'm ashamed to say that I took the easy way out.

 

Rick:

Obviously, they are being rated by how many bugs fixed.

We have moved on from being rated by lines of code. Cool.

<obligatory Dilbert and minivan reference>

 At a previous job, we once made the mistake of telling one of our more WTF-worthy customers how to turn on debug logging.

The next day, we found that they'd opened a slew of tickets, one for every place where the word "error" appeared in this 10,000 line log file.

Even for things like "Config file: ERROR: file not found - using defaults".

 

Wrongfellow:

At a previous job, we once made the mistake of telling one of our more WTF-worthy customers how to turn on debug logging.

 

If you had to tell them that, what made you think they were capable of interpreting the log even slightly?

What makes you think we expected them to be capable of interpreting it?

Have you never asked anyone to turn on tracing and send you the resulting log?

 

Wrongfellow:

Have you never asked anyone to turn on tracing and send you the resulting log?

 

Yes.

What I haven't done is tell them to raise a ticket for any perceived error in the log.

What I did was to instruct them how to turn on tracing, what to do with the results, and how to turn tracing off again so that they'd follow my procedures so that the resulting information would find itself in front of the right eyes.

Which one did you fall down on here?

OK, I've re-read my original post looking for the place where I said anything about asking them to open tickets, and I'm afraid I can't find it. Could you perhaps quote it for me, so I know what you're responding to?

 

Cassidy:

What I did was to instruct them how to turn on tracing, what to do with the results, and how to turn tracing off again so that they'd follow my procedures so that the resulting information would find itself in front of the right eyes.

You have clients who can follow simple instructions?!

Wrongfellow:

OK, I've re-read my original post looking for the place where I said anything about asking them to open tickets, and I'm afraid I can't find it. Could you perhaps quote it for me, so I know what you're responding to?

 

No, but I can quote this part:

Wrongfellow:

The next day, we found that they'd opened a slew of tickets, one for every place where the word "error" appeared in this 10,000 line log file.

Meaning: the reason why they opened the tickets is possibly down to a lack of instruction, where someone didn't make it clear what to DO with the logfile.

It's trying to bridge the gap in relevance between "haven't you ever asked the customer for a tracefile" and "why was one one ticket raised per tracefile content".

Let's put this in context here, shall we? Specifically, this bit of context:

 

Wrongfellow:

Have you never asked anyone to turn on tracing and send you the resulting log?

(Emphasis added for the benefit of the hard of thinking.)

 

Wrongfellow:

 At a previous job, we once made the mistake of telling one of our more WTF-worthy customers how to turn on debug logging.

The next day, we found that they'd opened a slew of tickets, one for every place where the word "error" appeared in this 10,000 line log file.

Even for things like "Config file: ERROR: file not found - using defaults".

You should never use the word error unless you mean it. A human should understand it in context, but a grep search can't. This is a valid bug, although low priority.

 

 

 

Rick:

Wrongfellow:

 At a previous job, we once made the mistake of telling one of our more WTF-worthy customers how to turn on debug logging.

The next day, we found that they'd opened a slew of tickets, one for every place where the word "error" appeared in this 10,000 line log file.

Even for things like "Config file: ERROR: file not found - using defaults".

You should never use the word error unless you mean it. A human should understand it in context, but a grep search can't. This is a valid bug, although low priority.

 

 

 

It's a log file. Perhaps the purpose of the log is to log any output messages. In that case the bug isn't valid, because if you want to open a file and it doesn't exist, that may well be an error for whatever piece of software is responsible for opening it. Ergo, the error message is valid, therefore (assuming that my hypothesis is correct) the log message is valid.

That's only an error if your program knows for sure the "config file" should be at that location. If it's first-run, it isn't, that's expected, and it's not an error. It's not even a warning, really.

Not your client's fault your team doesn't know what the word "error" means.

blakeyrat:

Not your client's fault your team doesn't know what the word "error" means.

 

blakeyrat and I agreed on something, TRWTF!!!

Wrongfellow:

(Emphasis added for the benefit of the hard of thinking.)

 

Yeah... I'm still thinking there's a gap between "can you send us the resulting log" and "we found that they'd opened a slew of tickets" that's being overlooked.

As pointed out before: yes...I have asked people to send me logfiles. And when given that directive, I received what I'd asked for: an email attachment - I didn't experience "they'd opened a slew of tickets", so I'm still mystified.

Are you saying you specifically gave them the instruction "can you send us the resulting log" but they misinterpreted it and "they'd opened a slew of tickets"...?

pjt33:

You have clients who can follow simple instructions?!

 

Given carte blance to spend any amount of time in dumbing down instructions to their most simplest, accompanied by photographs of the decaying carcass of the last client that failed to follow them... it is possible.

Oddly, our organisation is one that has "sacked the client" in the past - we've terminated contracts for fuckwittery that's cost us.

Cassidy:

Yeah... I'm still thinking there's a gap between "can you send us the resulting log" and "we found that they'd opened a slew of tickets" that's being overlooked.

"Can you turn on debug logging, and send me the resultant log?"

"Sure! I'll get it to you tomorrow."

SOON:

"OMG, what are all these ERRORs??? I'd better file some bugs against them so they get fixed! Oh, and I guess I should send off the log as well."

So.. is TRWTF that the client didn't follow WrongFellow's instructions?

pkmnfrk:

"Can you turn on debug logging, and send me the resultant log?"

"Sure! I'll get it to you tomorrow."

SOON:

"OMG, what are all these ERRORs??? I'd better file some bugs against them so they get fixed! Oh, and I guess I should send off the log as well."

 

Exactly. It's good to know there are still people on here who are interested in sharing anecdotes, rather than just being argumentative for the sake of it.

 

Wrongfellow:

It's good to know there are still people on here who are interested in sharing anecdotes, rather than just being argumentative for the sake of it.

No, we're not.

Wrongfellow:

Let's put this in context here, shall we? Specifically, this bit of context:

Protip: context goes before the anecdote, not after it.

TRWTF: 794 columns? you're doing it wrong.

realmerlyn:

TRWTF: 794 columns? you're doing it wrong.

snoofle has already said why he has these enormous tables, and it's for performance.  Welcome to 2012.

realmerlyn:

you're doing it wrong

 

Read the other thread. He's justified why it's that many columns.

Then you'll see why he's actually doing it RIGHT.

Wrongfellow:

 At a previous job, we once made the mistake of telling one of our more WTF-worthy customers how to turn on debug logging.

Here we make a product so full of WTF that it has become timing sensitive to the point that it no longer works if we turn debug logging OFF.

As a result it is constantly spewing garbage out of its serial port, fortunately the customer doesn't see it because in normal use nothing is plugged into it.

However, also make a product that outputs to a printer and the customer has asked "Can we have a printer on WTFPRODUCT like OTHERPRODUCT."

They've had a go a hacking it in but because removing certain bits of debug causes the device to crash, every now and again things will pop up in the middle of results if you happening to be printing at the wrong moment, like GPS TIMER RESET!

Cassidy:

realmerlyn:

you're doing it wrong

 

Read the other thread. He's justified why it's that many columns.

Then you'll see why he's actually doing it RIGHT.

Also, he's a contracted developer and not a DBA or software architect - it may not be up to snoofle in the first place.