Users Are Evil
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
-
I'm not understanding your comment. This is a case where the user is claiming to have not edited a file after doing extensive editing. We certainly don't have back up issues.
MehGerbil wrote:
We certainly don't have back up issues.
Wel the user seems to have got your back up! :laugh:
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
MehGerbil wrote:
We certainly don't have back up issues.
Wel the user seems to have got your back up! :laugh:
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
Users, who needs them? Often times when my boss tells me of a user reporting an issue I say the user is crazy. There is no way it happened the way they said it did. And sure enough, almost all of the time I am right. When you get them to show you what they did it is often not even close to what they said they had done. Good thing we aren't users, right? ;)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Users, who needs them? Often times when my boss tells me of a user reporting an issue I say the user is crazy. There is no way it happened the way they said it did. And sure enough, almost all of the time I am right. When you get them to show you what they did it is often not even close to what they said they had done. Good thing we aren't users, right? ;)
There are only 10 types of people in the world, those who understand binary and those who don't.
ryanb31 wrote:
Often times when my boss tells me of a user reporting an issue I say the user is crazy. There is no way it happened the way they said it did. And sure enough, almost all of the time I am right. When you get them to show you what they did it is often not even close to what they said they had done.
Whenever I'm accosted with some horrendous bug on some simple operation that a user ran into - an operation that has been in the software unmodified for years - I repeatedly say, "There's more to the story. They're not telling us something." "Nope, that's what they're saying." "That can't happen." "They say it is." "It ran for 4 years just fine then suddenly acted up. Did they ever update their software?" "No." "So did the software get rusty? Does it need its oil changed?" "What?" "JUST GET MORE INFO!" Invariably there's either something completely unrelated to what they originally said or they withheld some import information like - and I'm not kidding - rewiring something that just happened to correspond to the day it stopped working. Also, we log everything the customer does, so we can go step by step through what they did. "So, you lowered the alarm threshold at 12:53 PM on Tuesday, and the next time you ran it the alarm went off unexpectedly." Gah.
Look at me still talking when there's science to do When I look out there it makes me glad I'm not you
-
ryanb31 wrote:
Often times when my boss tells me of a user reporting an issue I say the user is crazy. There is no way it happened the way they said it did. And sure enough, almost all of the time I am right. When you get them to show you what they did it is often not even close to what they said they had done.
Whenever I'm accosted with some horrendous bug on some simple operation that a user ran into - an operation that has been in the software unmodified for years - I repeatedly say, "There's more to the story. They're not telling us something." "Nope, that's what they're saying." "That can't happen." "They say it is." "It ran for 4 years just fine then suddenly acted up. Did they ever update their software?" "No." "So did the software get rusty? Does it need its oil changed?" "What?" "JUST GET MORE INFO!" Invariably there's either something completely unrelated to what they originally said or they withheld some import information like - and I'm not kidding - rewiring something that just happened to correspond to the day it stopped working. Also, we log everything the customer does, so we can go step by step through what they did. "So, you lowered the alarm threshold at 12:53 PM on Tuesday, and the next time you ran it the alarm went off unexpectedly." Gah.
Look at me still talking when there's science to do When I look out there it makes me glad I'm not you
:)
Quote:
"It ran for 4 years just fine then suddenly acted up."
That's because code evolves right? Ghosts in the machines? Code is stupid. It does exactly what it is told, nothing more and nothing less.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
:)
Quote:
"It ran for 4 years just fine then suddenly acted up."
That's because code evolves right? Ghosts in the machines? Code is stupid. It does exactly what it is told, nothing more and nothing less.
There are only 10 types of people in the world, those who understand binary and those who don't.
However there may be cases you haven't foreseen and it suddenly acts up just because "it does exactly what it is told" ;) good examples are the leapyear and summer time / standard time changes ;) I remember that the whole windows azure went down because of a bug with this. Linky Link[^]
-
I'm not sure where you're going with this Giffy, but based on your posting history I'm going to fire off the eject seat now and hope I land in a pillow field.
Put down the ejection handle! It's an English phrase you probably haven't heard of: Get Your Back Up[^]
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
However there may be cases you haven't foreseen and it suddenly acts up just because "it does exactly what it is told" ;) good examples are the leapyear and summer time / standard time changes ;) I remember that the whole windows azure went down because of a bug with this. Linky Link[^]
Good point. I had to fix a weird bug where a previous developer download some code off the internet, compiled it into a dll, but hard-coded October 2010 as the last date this particular function would keep working. Luckily I found the source code online, downloaded it, made our small custom change, and did not include his ridiculous time bomb. :)
There are only 10 types of people in the world, those who understand binary and those who don't.
-
However there may be cases you haven't foreseen and it suddenly acts up just because "it does exactly what it is told" ;) good examples are the leapyear and summer time / standard time changes ;) I remember that the whole windows azure went down because of a bug with this. Linky Link[^]
Nicholas Marty wrote:
However there may be cases you haven't foreseen and it suddenly acts up just because "it does exactly what it is told" ;) good examples are the leapyear and summer time / standard time changes
That is a very good point. Kidding aside, I take every report seriously and investigate it as if it may be true. But sometimes it becomes clear very quickly that they're not telling us everything. I won't say there's nothing wrong (until I can prove it) - just that given the info they provide, there is something missing that prevents me from reproducing it. I give them the benefit of the doubt for as long as I can stand it. I let our product support people put it diplomatically.
Look at me still talking when there's science to do When I look out there it makes me glad I'm not you
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
MehGerbil wrote:
Users Are Evil Stupid
FTFY
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
I'm not understanding your comment. This is a case where the user is claiming to have not edited a file after doing extensive editing. We certainly don't have back up issues.
MehGerbil wrote:
This is a case where the user is claiming to have not edited a file after doing extensive editing.
We certainly don't have back up issues.Really?! It certainly sounds like the user is a backup problem; it's denial was nothing but sewage after all.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
MehGerbil wrote:
Users Are Evil Stupid
FTFY
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
and that's different how?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
and that's different how?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert EinsteinI would suppose it is a difference of intent.
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
I would suppose it is a difference of intent.
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
well ok. I guess that follows the axiom, "don't attribute to malevolence what can more easily be attributed to stupidity"
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
well ok. I guess that follows the axiom, "don't attribute to malevolence what can more easily be attributed to stupidity"
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einsteinahmed zahmed wrote:
"don't attribute to malevolence what can more easily be attributed to stupidity"
That's what I was going for there. In practice, you want to slam their head in a car door either way.
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
You can literally sit in a meeting with a user, look her in the eye and say, "I need a copy of this file as it comes from the bank - DO NOT EDIT IT" and she'll shake her head as if to indicate understanding. The user will then: 1: Download the bank file. 2: Open the comma delimited file in Notepad. 3: Do a find/replace on a few broken values. 4: Save the file. 5: Open it in Excel and change the column order. 6: Delete several rows that are 'gibberish'. 7: Add a few rows that have to be there for it to work properly. 8: Export the file as tab delimited. 9: Attach it to an email with the following message in the body: "This is the file I received from the bank". I had a developer in my office this morning pulling her hair out over this issue because after 6 months of development we are only now getting the actual bank file. Of course, the new file is easy enough to import but the changes the user was making masked a few problem areas that need to now be addressed. The people who know the least about a process are your users. You'd do better to ask a random stranger. I know my boss has always been critical of my methods but when I go to create a system I usually don't even look at the system I'm replacing or any of it's documentation because that confusing nest of lies will only add 50% to the development time. The reality is that user authored documentation is at best a wild guess and most likely intentional corporate sabotage authored by a demon possessed sadists.
There's something wrong with your process, if you rely on: -1. A user manual upload into a specified format you expect. -2. The format may change in time, that bank file. -3. version of office/excel will change, and so will the format. You need to bypass the middle-man user, get the data from the source, xml, rss,... Automate step 7. If the user CAN make a mistake, he WILL make a mistake.
