The Developer Is Always Wrong
-
Eddy Vluggen wrote:
If the client wants to cross the pacific ocean in a volkswagen, I'l tell him he'll die.
And if he still insists, you probably throw a life vest and an oxygen bottle onto the back seat and wish him a good voyage :) I call that learning by pain.
At least artificial intelligence already is superior to natural stupidity
-
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.
Well...the customer isn't always right, bt he does tend to get an unnatural amount of slack!
Along with that, always remember the First Rule of Management:
"Everything is easy for the man who doesn't have to do it himself."
[Scott Adams, I think.]
(This message is programming you in ways you cannot detect. Be afraid.)
-
I used to work for the military in the UK, in SW. The guys were doing a project for the Swedish navy, a sonar system. They left, by mistake, an error message that read "You tit Sven" in the code. And guess what. Yep, the Swedish Navy hit that line of code, and were mighty pissed off! :laugh:
Well that's not really the same as the OP's original complaint. That's just bad coding practices. NEVER put in anything that would upset someone, even in early stages. You never know what is going to ship by accident.
-
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.
-
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.
Had a similar issue when writing an online booking system for a hotel chain. The Manager was happy as a pig in poop with things, but then all of a sudden it stopped letting her sign in to the system. As she was the main admin this was a bit of a problem. 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? Got to love end users... Danny
-
Had a similar issue when writing an online booking system for a hotel chain. The Manager was happy as a pig in poop with things, but then all of a sudden it stopped letting her sign in to the system. As she was the main admin this was a bit of a problem. 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? Got to love end users... Danny
-
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.