|
Bigus Dickus.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Naughtius Maximus
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
Incontinentia Buttocks
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Excuse me? Are you the Judean People's Front?
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
F*** off! We're the People's Front of Judea!
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Throw him to the floor wrigorously centurion!
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I want him fighting wabid, wild animals within a week.
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre.
Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
|
|
|
|
|
We recently closed down a server and started up a new one.
For most items the transition was seamless.
However, one little orphaned script in our ITS department was looking for a file in a directory that it could no longer reach. I received the help desk call. I checked the date on the file and the last time it was modified was September 8, 2009.
The application owner never had the job shut off.
For the past four years our ITS department has been grabbing the exact same file and printing a report.
O.o
|
|
|
|
|
Ah, that's called learning from history.
It should be mandatory to read all reports from four years ago -- because it's damned sure that people were making the same mistakes then as they are now, and that all the "new" ideas put forward in meetings today have probably been proposed a dozen times in the past.
I'd promote the person responsible, for taking such initiative.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You should routinely stop all automatically generated reports from running, and then only reactivate those which someone complains about. And then only after asking them why they actually want it. More often than not the answer to that will be "because we always get it".
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
|
|
|
|
|
Ya know, as little as 5 years ago I would have thought this was a joke.
But I've seen horrible horrible things and have finally come to terms that this kind of occasional disruption of 'fringe' production systems is absolutely necessary.
|
|
|
|
|
I have been pushing for something similar. We have so many broken or non-functional automatic and manually generated reports in our system.
The solution agreed upon was "If it is broken and someone complains, we can investigate fixing or removing it. Otherwise, don't worry about it."
Arg! Just invest the time and fix the problem before someone notices it! Be pro-active!
|
|
|
|
|
RJOberg wrote: Arg! Just invest the time and fix the problem before someone notices it!
Well, in this case, there wasn't "a problem" until someone noticed it. Then, the problem wasn't that the code wouldn't work, but that it did work and effectively did nothing. The proposed solutions would generate problems of their own but remove the one encountered. (Which will remain tough to spot.)
Sometimes you don't know there is a problem until you get an unrelated one like this.
|
|
|
|
|
My team as a whole is trying to be more proactive in bug fixes. More reporting of errors back to the devs so we don't have to rely on a user filing a report, or waiting a week for it to get through the help desk and to us.
In my case it is a problem, the system has functionality which is broken and doesn't work. Users have gotten so used to this fact that we don't always get error reports from them. Like I mentioned, the system is not one we developed but are having to maintain and update. So we can only fix problems if we know about them.
When we find things that the original team said they had implemented but didn't, only half implemented but never finished, or just implemented in a broken fashion, we want to get them fixed. Chances are someone else already noticed the bug but didn't tell us because the old developers ignored them.
|
|
|
|
|
RJOberg wrote: Chances are someone else already noticed the bug but didn't tell us because the old developers ignored them.
I can't say for sure, but I get the feeling this is an endemic problem in the industry. Or at least, SOMEONE ignored them. Really, what is the point in reporting problems when you are just going to be ignored? Getting the word out that the team has changed, the focus is different, you will be listened to and action will be taken can be tough because the prior team didn't document who their customers were.
|
|
|
|
|
Agreed that it is kind of universal but across all industries, not just ours. I still occasionally get that feeling when I as a developer contacts a company for help when their product is misbehaving. Plus I get ignored by sales when I request any sort of technical information about a new product we are interested in purchasing.
Here we are dealing with the fact that our customers still feel that way. It is what you get when you start with a bad product and bad external support. You have to overcome all of those old beliefs and expectations when you now a half-way acceptable product with inside support staff who do their best to provide fast and accurate feedback. Every release gets better, so maybe by the time we retire it they will trust us again. Just in time to screw it up with the new version. 
Fortunately, we know exactly who is the customer base. Unfortunately, as with any group, if you have 100 people you get 100 opinions on how it should work and no one can agree or compromise.
|
|
|
|
|
RJOberg wrote: ... opinions on how it should work and no one can agree or compromise.
You know, maybe I have been associating with a better class of people lately? Ten years ago, I'd have totally agreed. Either I've mellowed enough that I don't put other people's hackles up or they've gotten more mellow when they disagree so it doesn't feel like they are totally ignoring what I say.
I opened an E-mail saying there are three kinds of lies, 1. lies, 2. D@mn lies, and 3. statistics. I agreed the report did accurately report an average, but then I showed 3 other ways to accurately get 3 different numbers where all were an "accurate" average with a vote of one of my three as the best way. The product manager agreed with me, that it was the best way to calculate it.
Ten years ago, I'd tell them, this is the way to calculate the average and there was a 50-50 chance that the team would agree with me. When they go another way, I'd privately disagree, but support their decision. (Sometimes gnashing my teeth.)
|
|
|
|
|
KP Lee wrote: You know, maybe I have been associating with a better class of people lately?
The various opinions comment was a bit of a hyperbole. For the most part our users are fairly good and many of them give constructive feedback about what they would like changed. Many of them feel that if certain changes were made, it would make how they use the product easier. The problem is that these changes can be at odds with what other users would make their experience better since each one uses different parts of the system more heavily or in different ways than others. Then we have the vocal minority who have no problem calling upper management directly to voice their opinions about why everyone else is wrong.
For the most part our developers, design staff, and product staff work very well together and hash out ideas that work for the majority of the users given the limitations we work within. We disagree from time to time but can compromise on what would work best.
This job would be fantastic if it weren't for the users. 
|
|
|
|
|
I recently had the same experience!
We are updating a program used by our entire customer base, I got tasked with updating a report used to create mailing labels. Should have been an easy fix, we already had the report updated and approved for the last deployment, but it got missed by the person deploying the new package (old system, don't ask).
So, I deployed it to the test environment just to make sure that it was the right one. It tested okay in all the methods to print except for the one which schedules large jobs to be run in off hours. Kept failing and saying that it had too many parameters. So I dug in and checked why...
Apparently 22 months ago, the system was updated and the stored proc had five parameters removed. All of the other methods to print had been updated and tested, but this last one had not. I reported back the cause and they couldn't believe no one had used that print method for over a year and a half. Checked the logs, sure enough the last successful run was late 2011. Been throwing errors ever since and no one thought to notify us about it. Again, old system, we didn't build it, wasn't designed very well, not very good error reporting.
Their final decision on how to proceed? No one has noticed it for almost two years. We will mark it as a known bug and fix it in a later build.
|
|
|
|
|
RJOberg wrote: We will mark it as a known bug and fix it in a later build.
Pretty SOP. If you have something that doesn't work, but is also non-critical let it keep failing until the next release. However, do note the error and assign someone to fix it.
Emergency releases do occur, but rarely, and just for this reason is it rare.
Some of these problems are really strange. I reported to the development group that they had slow running processes in SQL because they were executing functions that produced constant values in where clauses.
I explained that the field is indexed and SQL is too dumb to realize it is producing a constant so it executed the function against every row in the table instead of using the index's b-tree to find the exact rows it wanted to look up.
Next release, I noted they had changed their maintenance routines by setting the GETDATE() calculation into a variable and asked because it wasn't a constant result. "This is a daily maintenance, we'll clean up the rest of the data the next day"
Perfectly reasonable idea to me, let it pass. Next release the maintenance jobs started to consistently start taking over 24 hours, then 48, then 72... That resulted in an emergency fix and even then it was days after it was found before they were ready to release it.
|
|
|
|
|
There is a slight difference though, the bug was put into production two years ago, since then there has been at least 4 or 5 releases. During that entire time, users have been getting errors and no one thought to notify the people who could fix it.
Other bugs, major like null values in fields that should never be null, and minor, like grammatical, spelling, or punctuation errors have been reported, but not the fact that a nasty exception text window has been popping up whenever anyone tries to run any report overnight.
If we had known about this before the last week of testing we might have been able to fix it. Oh, plus it is in .Net 1.0 and created in VS 2003 and no one has been kind enough to get the dev team a copy from the company's MSDN account, if it is even still available there (in 2010 it still was). So we have to migrate it up and debug any problems which arise from doing so.
|
|
|
|
|
I've never seen a report that was actually read.
|
|
|
|
|
Wouldn't thank make you part of the problem, as every report you've seen you've refused to read?
|
|
|
|
|
I guess so. None of them were meant to be read by me though.
|
|
|
|
|
We Moved over from an old AS/400 based system about 2 years ago, it had been around for almost 2 decades. With that we hired a slew of new staff, in their training one of them asked a question along the lines of:
What do I do with these 50 pages of reports that print on my printer ever morning?
they were told to shred them, they print every morning for "some reason" and nobody knew why.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
