If a process produces a report that nobody reads...
-
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.
I worked for a very large company. They printed lots of reports every day from their huge bank of high speed mainframe printers (by the pallet load of paper). At one point a project started to try to move to online reports instead of printing and delivering them. One lady pitched a fit when her reports didn't show up one day. So, someone went over to see what happened to all these printed reports that were needed so desparately. So the person that went over watched as she separated the various reports, carefully placed each one in a labeled binder and filed it away in the large room behind her desk. By now it was late afternoon and the person asked her what happens to them now? She said I've got them filed away now and I can go home in a half an hour. So he pursued a little more, well who comes to look at them now. She replied (with a straight face even) "Oh, nobody ever comes to look at them, I just file them away". Cause, you know, that's her job. She didn't have a job much longer and they stopped printing that truckload of reports (about 2 1/2 pallets of paper) everyday. Then the reports were just turned off and nobody ever called to complain.
-
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
Way back in the days of machines that took up an entire floor of a good-sized building, I became responsible for a report that, when printed, consumed about eight inches of 132 column paper. It was produced monthly and distributed to about 50 addressees. I asked my manager if we could stop producing the report. He was cautious since the report had been requested by one of our customers So, to insure that nobody read it, I added a few pages to the report at random locations. The added pages simply stated that the report was under consideration for deletion and, that if the reader wanted it continued, the preparing organization needed to be advised. The report ran for six more months. After that, with no one asking that it be continued, the report was discontinued. About six months after it was discontinued, we received a call asking where the report was. When told that it had been discontinued six months earlier, the caller just said "thanks" and hung up. Guess he really didn't need it.
Gus Gustafson
-
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.
-
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.
-
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:
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.
-
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.
-
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. ;P 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.
-
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. ;P 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.)
-
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. ;)