Users Are Evil
-
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.
-
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 not "not knowing the process", this is utter dumbness. When one say "Do not edit", then all it takes not to edit is is a basic understanding of the English language.
-
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.
Our problem was that the 3rd party data suppliers kept changing their formats without warning. We ended up writing programs that parsed the data looking for key phrases instead of expecting a set format. The best ones were the Excel spreadsheets that they changed the layouts and in their defense said, "We highlighted the changes in yellow." I eventually wrote a program to detect background colors instead of just reading the values in the cells. Strictly speaking it's not bank data, but for credit card processing and the data is support of those operations. I have no one to blame but myself, the original person who dealt with the data would edit all the files by hand before submitting them for processing. I declared that method was insane because it took him a week to clean up the data and the automated solution took only five minutes. It took us a while to catch on to the fact that the 3rd party vendors were changing the formats of the files we were feeding the automated process and then had to install all sorts of checks and interpreters maintain the automated operation.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
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.
I find the problem in this case is that what the user thinks they did and what they actually did are two different things. This is such a recurring problem we include a 'diagnostic trace' facility that records a crap-pile of stuff about what the system is doing. We routinely tell the user to repeat the process that failed and record a trace while doing so.
Software Zen:
delete this; -
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 where you need to have a cricket bat in the office. Write the users name on it and then when they do this again phone them up to say "Somewhere there is a cricket bat with your name on it" - you can't get told off for threatening them with physical violence as you're only telling the truth :-D