Users Are Evil
-
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.
-
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'd sit with the user diagramming what they do(if you can't then screen record it). That way -- you make sure they attach the file directly from the point it was generated. -Rule #1: Trust no one.
-
I'd sit with the user diagramming what they do(if you can't then screen record it). That way -- you make sure they attach the file directly from the point it was generated. -Rule #1: Trust no one.
I've been using creately to diagram -- you can do it over the web that way. Also, 'box' has a pretty good screen record-capture facility.
-
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.
I agree; however, many times what we can do is limited by the bank/organization/agency. If you knew how shoddy banks are with data you'd probably hide your money under a pillow. I'd love to have an automated process that grabs the file and uploads it seamlessly in the background.
-
I agree; however, many times what we can do is limited by the bank/organization/agency. If you knew how shoddy banks are with data you'd probably hide your money under a pillow. I'd love to have an automated process that grabs the file and uploads it seamlessly in the background.
Especially if it's banking related... What happens if you import a item_text from cell C5... But cell C5 says something like alert('XSS!'), with possible variations to mask the < symbol.. You're not protected by asp.net anymore "A potentially dangerous...". There is no form. You must handle ALL validation in the code I assume... NEVER trust user uploads...
MehGerbil wrote:
If you knew how shoddy banks are with data you'd probably hide your money under a pillow.
Trust me, I know. I'm a programmer, refusing to access his own bank account via web... So I used to go directly (old school style) for transfers; but then last time I get these clueless computertards doing it for me, from their computer! (more likely to be infected than mine). I also saw how easily I could have, well, while she was, well, don't wanna give any ideas (puts infected usb back in pocket)...
-
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.
Get a hold of yourself. This woman would not have 2) Open the comma delimited file in Notepad. 3)Do a fin/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 IF SHE DID NOT THINK THAT SHE HAD TO DO IT!!!! The people who know the least about a process are programmers and analysts who do not bother to ask the end user what they do. I'd wager dollars to doughnuts that the majority of formal processes that exist in organizations bear little if any relation to the actual process that gets the task done. Any programmer and/or analyst who believes a manager who says "Here is the formal process. This is the way that we do things." deserves to be frustrated - he/she is not living in the real world.
-
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.
Revenge is sweet. If you can't beat them. Convert them! There was once had worker in a client, that managed to find all manner of problems with everything. Her favourite line was 'I didn't touch anything!'. Some years later I hired her, and one day when she was in a client I heard her say to someone "What did you touch? What did you touch and don't tell me you didn't touch anything 'cause thats what I used to say!" There is always two sides to every story, eh?
-
Get a hold of yourself. This woman would not have 2) Open the comma delimited file in Notepad. 3)Do a fin/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 IF SHE DID NOT THINK THAT SHE HAD TO DO IT!!!! The people who know the least about a process are programmers and analysts who do not bother to ask the end user what they do. I'd wager dollars to doughnuts that the majority of formal processes that exist in organizations bear little if any relation to the actual process that gets the task done. Any programmer and/or analyst who believes a manager who says "Here is the formal process. This is the way that we do things." deserves to be frustrated - he/she is not living in the real world.
Are you indirectly saying that managers live in a fantasy world? because what they say cant be trusted. Then most of management must be useless and only serve to the bureaucracy. I am starting to think that automation just are used to make more stupid process than ever, instead of more logical and optimum process. The bureaucracy is just expanding exponentially now.
-
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.
This is a rather immature (from a developer standpoint) point of view. Users aren't evil. Users are helpful. Sometimes their help breaks things (like when they tidy up files). Users are forgetful. Sometimes they can't remember what was in the beautiful error dialog you wrote. Users are uneducated. Just because you went to MIT doesn't mean the clerk reporting the problem has a 140 I.Q. Users are patient. Sometimes they put up with a bug for weeks and weeks before it annoys them enough to report it. Then they can't remember the first time it happened. Users are busy. Writing bug reports isn't the only thing they have to do today. And it's not the thing that they get graded on at their next performance review. Users have no idea how your code works. They make mental models to help them understand your code. Sometimes these hypotheses are not very close to the way your code works. When users report problems, they report in context of their mental model, not the actual structure of your code. Users are frustrating and difficult and irritating, but they aren't evil. And here's the thing, if your code doesn't detect failures, doesn't log failures so you can see just what went wrong, doesn't provide an obvious model of how it is working, doesn't explain errors in language a high school sophomore could understand, then it's the code, not the user, that is evil. Users are what they are. If your code doesn't handle that, then your code is broken. Period. End of story.
-
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.
That's why i prefer to work with robots and neural networks, they're less... evil. ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Are you indirectly saying that managers live in a fantasy world? because what they say cant be trusted. Then most of management must be useless and only serve to the bureaucracy. I am starting to think that automation just are used to make more stupid process than ever, instead of more logical and optimum process. The bureaucracy is just expanding exponentially now.
In my humble opinion, there are three types of managers. The first type has been promoted to his level of incompetence, a la Peter Principle, eg, the crackerjack project manager who is a bumbler as a department head. The second type wants to promulgate complexity, in order to make himself look better - the classic pointy haired boss in Dilbert. The third type, very rare, but responsible for the bulk of any organization's success, is the one who knows what needs to be done, understands that he cannot do it alone, finds the best people for the jobs that he creates, and let's them go to work, and clears roadblocks.
-
This is a rather immature (from a developer standpoint) point of view. Users aren't evil. Users are helpful. Sometimes their help breaks things (like when they tidy up files). Users are forgetful. Sometimes they can't remember what was in the beautiful error dialog you wrote. Users are uneducated. Just because you went to MIT doesn't mean the clerk reporting the problem has a 140 I.Q. Users are patient. Sometimes they put up with a bug for weeks and weeks before it annoys them enough to report it. Then they can't remember the first time it happened. Users are busy. Writing bug reports isn't the only thing they have to do today. And it's not the thing that they get graded on at their next performance review. Users have no idea how your code works. They make mental models to help them understand your code. Sometimes these hypotheses are not very close to the way your code works. When users report problems, they report in context of their mental model, not the actual structure of your code. Users are frustrating and difficult and irritating, but they aren't evil. And here's the thing, if your code doesn't detect failures, doesn't log failures so you can see just what went wrong, doesn't provide an obvious model of how it is working, doesn't explain errors in language a high school sophomore could understand, then it's the code, not the user, that is evil. Users are what they are. If your code doesn't handle that, then your code is broken. Period. End of story.
-
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.