The Developer Is Always Wrong
-
Danny Martin wrote:
... Her username was the name of her second cat or something equally peculiar, and her password was her home postcode.
Can you guess the problem? ...Let me guess. Did she move to an area with a different postcode? :doh:
She did... My software's good and all - but Geolocation was not on the spec sheet! ;P
-
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.
Here's another data import nightmare for you... I have a data import routine where one file contains "remark" entries. There are 17 million lines in this file and it's not tab-delimited, not comma-delimited, the lines are delimited by the string "~~~" between columns. Now for the fun... each line might be a self-contained remark containing 38 columns. Or the line might be a "starter" line that contains the first 30 columns. Or the line might be a "middle" line that is just an additional line of the current remark text. Or the line might be a useless line that just contains "..", which needs to be ignored. Or the line might be an "ending" line that contains the final eight columns, of which the first column may or may not contain the very end of the remark text. I have gone around and around with methods to import and process this data. My latest seems to be working OK, but it takes like 20 minutes to import and process this file. Unfortunately I have no leverage to get the source of this data to change, just got to live with it and do the best I can...
-
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.
Maybe there is a separate job here to write a program that helps the customer create the file in the appropriate format?
-
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...
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'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|
Surely you jest.... I never see stupid stuff building websites... Client has an eCommerce site, wants the developers to tell him shipping works. Not from the aspect of a website, just everyday shipping. Also wants us to tell him how to set up a Customer Service department. Another client couldn't get into their administration menu.... they weren't typing the URL into the address bar, they were doing a search for the URL on Y!
-
MehGerbil wrote:
customer is always right
Only if you're a prostitute. The customer isn't a specialist, has little information on legal implications, has no idea of ROI or TCO, and in general - doesn't care about these things. That's why they pay for an expert. If the expert acts like a prostitute, and gives the client exactly what he asked for merely to obtain the payment, then he is in fact acting in the same way. 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.
Bastard Programmer from Hell :suss:
Eddy Vluggen wrote:
If the client wants to cross the pacific ocean in a volkswagen, I'l tell him he'll die.
I'm pretty sure you haven't seen this movie: http://www.imdb.com/video/wab/vi146512921/[^]
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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.
-
Here's another data import nightmare for you... I have a data import routine where one file contains "remark" entries. There are 17 million lines in this file and it's not tab-delimited, not comma-delimited, the lines are delimited by the string "~~~" between columns. Now for the fun... each line might be a self-contained remark containing 38 columns. Or the line might be a "starter" line that contains the first 30 columns. Or the line might be a "middle" line that is just an additional line of the current remark text. Or the line might be a useless line that just contains "..", which needs to be ignored. Or the line might be an "ending" line that contains the final eight columns, of which the first column may or may not contain the very end of the remark text. I have gone around and around with methods to import and process this data. My latest seems to be working OK, but it takes like 20 minutes to import and process this file. Unfortunately I have no leverage to get the source of this data to change, just got to live with it and do the best I can...
It sounds like a place where i used to work, until, fortunately, they fired me. :-D
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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).
DukeWendel wrote:
to press Tab after each second word
You're making assumptions...
-
Surely you jest.... I never see stupid stuff building websites... Client has an eCommerce site, wants the developers to tell him shipping works. Not from the aspect of a website, just everyday shipping. Also wants us to tell him how to set up a Customer Service department. Another client couldn't get into their administration menu.... they weren't typing the URL into the address bar, they were doing a search for the URL on Y!
:laugh: What I meant is... there's really no complete way to anticipate what a user might do. You just have to try to limit the possibilities.
-
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