The Developer Is Always Wrong
-
It's the corollary to the customer is always right. I created a program that imports records from a customer provided text file. The file is tab delimited and it has a particular format. I wrote up a document that describes the format and our clients are to send us the file using that format. There is nothing complicated about any of the requirements. Most files we receive look like someone turned a monkey loose in Notepad. So a manager calls me up and wants to know why the file wouldn't import. I guess the error message "File has an invalid format" wasn't clear enough, but I digress. The point is that the manager was frustrated and the client was frustrated and despite the fact that they were breaking the rules (of the program) the long and short of it was my program wasn't working. In short, the developer is always wrong. I'm going to revisit the program today with an eye on making it so that you can freakin' import a terribly broken tab delimited text file, a comma delimited text file, a text file that is missing fields, a .PDF file, a .JPEG, a porn video or Doritos stuffed into the CD slot - I don't care. Whatever the case, it won't show an error message that describes the problem because that is obviously a waste of time.
I get my greatest pleasure writing code that works no matter how much the customer tries to screw it up. However, handling Doritos stuffed into the CD slot requires device driver programming, and you would probably need a license and some more information and maybe a little melted cheese, black olives and jalapenos.
-
Albert Holguin wrote:
Customers aren't always all that computer savvy...
I've heard this so many times... One dose not need to be computer savvy to press Tab after each second word(for example).
That is so cliched and arrogant. Our job as programmers is to enable our users, no matter what their skill levels, to interact successfully with the system we design. If they cannot, then we have failed our job. We have to remember that our users may not have 3-digit IQ's or schooling beyond grade school; that they may not be native english-speakers, they may have a physical handicap, and may be distracted by any number of other issues. Years ago another programmer I know was faced with the task of getting people whose main skill level was not being blind to enter vital data. She tried the customary textboxes and buttons, only to have the users require huge training and a high error rate. She came up with a large button with a cute rabbit on it. The users were trained to "type the number then push the bunny". It worked. While we haven't adopted actual animal graphics, we do have a process we call "to bunny-ize" whenever a part of our UI requires a lot of user support. Murray
-
MehGerbil wrote:
In short, the developer is always wrong.
I have actually heard this from a Manager once(A very top level guy). He also said one thing that was very condescending and upsetting. He said
"The reason I am not updating the technology is if our developers learn the new and cutting edge stuff then they will leave my company".
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
Rahul Rajat Singh wrote:
"The reason I am not updating the technology is if our developers learn the new and cutting edge stuff then they will leave my company".
Hey, I worked for him too! :laugh:
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.
-
That's always been the issue with using text files, it's too easy to put in something that wasn't expected and then the program doesn't work. Maybe you can force them to do it a certain way by doing something different, maybe make a simple GUI or a spreadsheet that has the fields defined instead of a text file. Customers aren't always all that computer savvy... X|
Albert Holguin wrote:
Customers aren't always all that computer savvy... X|
You can say that again. We had a program we wrote to parse Excel spreadsheets (the user's database) and our parser barfed on some file we were given that they had changed the format of certain records. Their explanation was that they had marked the records by highlighting them in yellow and it was our fault that we hadn't noticed the change. :wtf:
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.
-
For a professional, I expect a professional attitude. If the client wants to cross the pacific ocean in a volkswagen, I'l tell him he'll die.
Not much faith in the German automobile company haven't you? :-\
Hmm i wonder why its doing that......ARGHS NO STOP, ROLLBACK ROLLBACK...F*** That's how i learned to "Always Backup"!!
A famous National Lampoon faux ad did Teddy Kennedy[^] And for those of you too young to get the joke, Volkswagen used to have a commercial where they dumped a Beetle into the drink and you watched how slowly it sank. This was in response to the complaint that you had to roll the window down a bit in order to close the doors, they were so airtight.
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.
-
It's the corollary to the customer is always right. I created a program that imports records from a customer provided text file. The file is tab delimited and it has a particular format. I wrote up a document that describes the format and our clients are to send us the file using that format. There is nothing complicated about any of the requirements. Most files we receive look like someone turned a monkey loose in Notepad. So a manager calls me up and wants to know why the file wouldn't import. I guess the error message "File has an invalid format" wasn't clear enough, but I digress. The point is that the manager was frustrated and the client was frustrated and despite the fact that they were breaking the rules (of the program) the long and short of it was my program wasn't working. In short, the developer is always wrong. I'm going to revisit the program today with an eye on making it so that you can freakin' import a terribly broken tab delimited text file, a comma delimited text file, a text file that is missing fields, a .PDF file, a .JPEG, a porn video or Doritos stuffed into the CD slot - I don't care. Whatever the case, it won't show an error message that describes the problem because that is obviously a waste of time.
MehGerbil wrote:
import a terribly broken tab delimited text file, a comma delimited text file, a text file that is missing fields, a .PDF file, a .JPEG, a porn video or Doritos stuffed into the CD slot
I love it, I have to jump through the same hoops here too. I work in industrial control, and you would think there would be a certian level of brains behind the operators, but I can't take that for granted; as it has been proven over and over again. btw; my software did get blamed for downloading porn once, I had a hard time explaining to the owner of the facility that the software can't do that; just keep and eye on the operator for awhile. the issue resolved it's self in a week :laugh: -Good Luck :-D
-
It's the corollary to the customer is always right. I created a program that imports records from a customer provided text file. The file is tab delimited and it has a particular format. I wrote up a document that describes the format and our clients are to send us the file using that format. There is nothing complicated about any of the requirements. Most files we receive look like someone turned a monkey loose in Notepad. So a manager calls me up and wants to know why the file wouldn't import. I guess the error message "File has an invalid format" wasn't clear enough, but I digress. The point is that the manager was frustrated and the client was frustrated and despite the fact that they were breaking the rules (of the program) the long and short of it was my program wasn't working. In short, the developer is always wrong. I'm going to revisit the program today with an eye on making it so that you can freakin' import a terribly broken tab delimited text file, a comma delimited text file, a text file that is missing fields, a .PDF file, a .JPEG, a porn video or Doritos stuffed into the CD slot - I don't care. Whatever the case, it won't show an error message that describes the problem because that is obviously a waste of time.
Repeat after me. Tabs look like spaces. Spaces look like tabs. Because to your customers, they do. They're using 93 different text editors at their compan(ies) and every one has different defaults on how to handle the <TAB> key. None of them turns on "Show Special Characters" by default, so the tabs and the spaces look alike. They each live in their own personal bubbles. After 26 years in the business, I have seen this problem at least <insert scientific notation number here> times. Tabs as delimiters is a booby-trapped practice. Delimit some other way if you don't want this to occur all the time, forever.
-
Repeat after me. Tabs look like spaces. Spaces look like tabs. Because to your customers, they do. They're using 93 different text editors at their compan(ies) and every one has different defaults on how to handle the <TAB> key. None of them turns on "Show Special Characters" by default, so the tabs and the spaces look alike. They each live in their own personal bubbles. After 26 years in the business, I have seen this problem at least <insert scientific notation number here> times. Tabs as delimiters is a booby-trapped practice. Delimit some other way if you don't want this to occur all the time, forever.
I'd like to politely disagree. Use of any other delimination would result in chaos. For example, use of a comma would be destroyed by the field value 3,000,000.00. Use of any character would mandate that the character not be used in any of the fields. Use of any uncommon character would not allow the file to be generatd from Access/Excel. If you have a better suggestion, please offer it. (Seriously)
-
Albert Holguin wrote:
Customers aren't always all that computer savvy... X|
You can say that again. We had a program we wrote to parse Excel spreadsheets (the user's database) and our parser barfed on some file we were given that they had changed the format of certain records. Their explanation was that they had marked the records by highlighting them in yellow and it was our fault that we hadn't noticed the change. :wtf:
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.
BrainiacV wrote:
it was our fault that we hadn't noticed the change
:laugh: Think that's partially human nature... to think everyone else should think exactly the way you do.
-
It's the corollary to the customer is always right. I created a program that imports records from a customer provided text file. The file is tab delimited and it has a particular format. I wrote up a document that describes the format and our clients are to send us the file using that format. There is nothing complicated about any of the requirements. Most files we receive look like someone turned a monkey loose in Notepad. So a manager calls me up and wants to know why the file wouldn't import. I guess the error message "File has an invalid format" wasn't clear enough, but I digress. The point is that the manager was frustrated and the client was frustrated and despite the fact that they were breaking the rules (of the program) the long and short of it was my program wasn't working. In short, the developer is always wrong. I'm going to revisit the program today with an eye on making it so that you can freakin' import a terribly broken tab delimited text file, a comma delimited text file, a text file that is missing fields, a .PDF file, a .JPEG, a porn video or Doritos stuffed into the CD slot - I don't care. Whatever the case, it won't show an error message that describes the problem because that is obviously a waste of time.
This reminds me of years ago when we had hired an outside programmer to write a system that was to be shared by several agencies throughout our area. The problem was that the data was only available for viewing and not for downloading for local handling. This was when we only had modems for outside communication. I had to ask the "developer" to make a copy of the file available for downloading every time we needed the data. The problem was that he had to generate the file on demand and never gave us the information in the same order or format. We eventually fired him.
I'm not a programmer but I play one at the office
-
That's always been the issue with using text files, it's too easy to put in something that wasn't expected and then the program doesn't work. Maybe you can force them to do it a certain way by doing something different, maybe make a simple GUI or a spreadsheet that has the fields defined instead of a text file. Customers aren't always all that computer savvy... X|
I can't say for sure, but such files are usually computer-generated. It's often programmers at the other end that do a shitty job of exporting according to the rules. It is also my experience that by being patient and investing a lot of time describing the errors in such a way that your manager understands them too, and making it clear to him, in his language, that what he's asking from you _can not_ be properly imported, he'll eventually come around and tell the other end of the process to either provide sane input or go rub themselves. Your work costs your manager money, and if you make it clear to him that the costs aren't caused by you, he'll do his best to offload the costs onto some other manager.