Customers are idiots
-
We make commercial ink-jet printers. One of my applications includes a data base that is used to record production statistics. It is designed so that a single data base can support any number of printing systems. I just received a problem report from a customer who has installed a separate data base on each printing system and is complaining about its effect on performance. Apparently they use their own home-grown application to query each data base and to merge the data. :doh: :doh: :doh: :doh: :doh:
Software Zen:
delete this;
Fix-ed.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Fix-ed.
I wanna be a eunuchs developer! Pass me a bread knife!
-
WTF? How would it be maintained after you left? Who suggested that it would be a good idea not to document the app?
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC League Table Link CCC Link[^]
Dalek Dave wrote:
Who suggested that it would be a good idea not to document the app?
A contractor seeking permanent renewals?
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Dalek Dave wrote:
Who suggested that it would be a good idea not to document the app?
A contractor seeking permanent renewals?
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
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;
-
WTF? How would it be maintained after you left? Who suggested that it would be a good idea not to document the app?
------------------------------------ I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave CCC League Table Link CCC Link[^]
Those were internal applications and everything relied on comments in code. They never thought of maintaining it. The task for such applications was given to people on bench. Developers tried new code and language features on such applications. Also, project managers were showing to their superiors that they kept resource busy on internal applications and made something valuable. On a larger scale whole idea is crap. But, that all happened.
-
Those were internal applications and everything relied on comments in code. They never thought of maintaining it. The task for such applications was given to people on bench. Developers tried new code and language features on such applications. Also, project managers were showing to their superiors that they kept resource busy on internal applications and made something valuable. On a larger scale whole idea is crap. But, that all happened.
-
We make commercial ink-jet printers. One of my applications includes a data base that is used to record production statistics. It is designed so that a single data base can support any number of printing systems. I just received a problem report from a customer who has installed a separate data base on each printing system and is complaining about its effect on performance. Apparently they use their own home-grown application to query each data base and to merge the data. :doh: :doh: :doh: :doh: :doh:
Software Zen:
delete this;
-
"Customer is King" At least when he has budget for everything crap he wants us to do and keep us employed.
In this case, the Emperor still ain't wearing any clothes.
Software Zen:
delete this;
-
We make commercial ink-jet printers. One of my applications includes a data base that is used to record production statistics. It is designed so that a single data base can support any number of printing systems. I just received a problem report from a customer who has installed a separate data base on each printing system and is complaining about its effect on performance. Apparently they use their own home-grown application to query each data base and to merge the data. :doh: :doh: :doh: :doh: :doh:
Software Zen:
delete this;
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.
-
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;