Customers are idiots
-
But surely, if I only had one printing system, installing the software on that one system would be a sensible thing to do. If that doesn't have a negative effect on the performance of that system, why would installing the software say, three times, on three independant printing systems affect the performance of each system? The single database scheme may not work in all cases anyway. They may have remote sites connected via low-bandwidth links, there may be departmental politics issues where one department isn't permitted to see stats from another department etc, etc.
The single printing system configuration would be okay; in fact, our smaller customers do this fairly often. I don't believe that the data base inherently affects system performance, especially since it only writes small changes infrequently. That's something that the customer is claiming. I have a feeling their application which queries the data base on our machine is polling at a high rate, which causes the performance issue.
Electron Shepherd wrote:
The single database scheme may not work in all cases anyway. They may have remote sites connected via low-bandwidth links, there may be departmental politics issues where one department isn't permitted to see stats from another department etc, etc.
That may be true, but most data bases can be configured to deal with those issues, yet still maintain the central server.
Software Zen:
delete this; -
Fix-ed.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Actually they're not. I wrote the user guide. I explicitly tell them, in several places, to install the data base once on a server accessible to all of their printing systems. As I said, customers are idiots.
Software Zen:
delete this;Gary Wheeler wrote:
Actually they're not. I wrote the user guide. I explicitly tell them, in several places, to install the data base once on a server accessible to all of their printing systems.
Then you must have written it in the wrong place, "forgotten" to explain why, used different terms and terminology for the same thing without properly defining them, or not written it using language that they understand, otherwise, that would be what they did. I see this all the time: 1. Customer complains that something doesn't work they way they expected. 2. Developer says it's all explained in the user guide. 3. Customer is told RTFM. 4. Customer says that they have read the user guide, through and through, cover to cover, and back to front, and that there is nothing in it about the thing in question -- and that they're considering doing a PoC with a rival product. 5. Developer gets snitty, showing the thirteen different sections of the user guide that have to be referenced, in order to gather together enough information to maybe figure out how to do a simple thing that customers want to do every day. 6. It is pointed out to the developer that: -- Because the guide follows what the program does and how it works, rather than how to use it, it is almost impossible to refer to it to perform even the simplest of sequential activities. -- The wording used makes most of the little snippets of relevant information (that are dispersed randomly around the document) appear to bear no relevance to the topic (unless you look at class names, etc, in the code, which have nothing to do with how it's used). -- The way things are described and correlated can only be understood by people who understand the inner workings of the program -- i.e. the developer and his team. -- In the interest of "not being repetitive", critical elements described in the guide have been given different names almost every time they are mentioned, but there is no mention anywhere that, for example, the terms "external device manager", "plug-in options window" and "add-ons dialogue" all mean the same little pop-up dialogue. -- Because of omitted details and words (which everyone should know without being told -- unless they're idiots, of course), a lot of what is present is Wrong, and train wrecks are inevitable. -- Writing things simply and clearly is not only allowed, but it's recommended! 7. The developer blows a gasket,
-
Distind wrote:
You assume they read the user guide.
That's problem B. You normally find, though, that the staff who install products do actually RTFM -- or at least the overviews, to make sure there's nothing unusual.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Dalek Dave wrote:
Subtle!
I studied at the Brick through a Window school of Linguistics.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Gary Wheeler wrote:
Actually they're not. I wrote the user guide. I explicitly tell them, in several places, to install the data base once on a server accessible to all of their printing systems.
Then you must have written it in the wrong place, "forgotten" to explain why, used different terms and terminology for the same thing without properly defining them, or not written it using language that they understand, otherwise, that would be what they did. I see this all the time: 1. Customer complains that something doesn't work they way they expected. 2. Developer says it's all explained in the user guide. 3. Customer is told RTFM. 4. Customer says that they have read the user guide, through and through, cover to cover, and back to front, and that there is nothing in it about the thing in question -- and that they're considering doing a PoC with a rival product. 5. Developer gets snitty, showing the thirteen different sections of the user guide that have to be referenced, in order to gather together enough information to maybe figure out how to do a simple thing that customers want to do every day. 6. It is pointed out to the developer that: -- Because the guide follows what the program does and how it works, rather than how to use it, it is almost impossible to refer to it to perform even the simplest of sequential activities. -- The wording used makes most of the little snippets of relevant information (that are dispersed randomly around the document) appear to bear no relevance to the topic (unless you look at class names, etc, in the code, which have nothing to do with how it's used). -- The way things are described and correlated can only be understood by people who understand the inner workings of the program -- i.e. the developer and his team. -- In the interest of "not being repetitive", critical elements described in the guide have been given different names almost every time they are mentioned, but there is no mention anywhere that, for example, the terms "external device manager", "plug-in options window" and "add-ons dialogue" all mean the same little pop-up dialogue. -- Because of omitted details and words (which everyone should know without being told -- unless they're idiots, of course), a lot of what is present is Wrong, and train wrecks are inevitable. -- Writing things simply and clearly is not only allowed, but it's recommended! 7. The developer blows a gasket,
Hmm. I agree with your points. I can't prove I did those things without sending you the user guide, which is beyond the scope of a casual online discussion. Based on past experience with our customer IT staff, my user guide was written with small words and explicit step-by-step instructions. The typical customer IT guy is the owner's sister's boyfriend's second cousin. He opened a Facebook account, so this makes him an expert at managing data flow in a highly non-homogenous environment. Not to put too fine a point on it, but for every real expert, we see a lot of bottom feeders. Ergo, customers are idiots.
Software Zen:
delete this;