I think (from posts above) perhaps a better phrase is "customer expectation management".
If the customer has a million expections, but your Lead or Project Manager has not told the customer what to expect from their current "official" requirements, then you will have a disappointed customer. However, if you let the customer know, right from the start that the project will do exactly what they ask, and no more - then "extras" that were designed in through savvy programming, code re-use - or interface standarization, etc. will now be beyond the customer's expectations.
On the other hand, when a customer says, I want it to be like Excel, the Project Manager's first words should be, "why can't you use Excel?" - as opposed to "Sure, what about Excel do you want us to emulate?".
I believe your description is speaking to "weak-US style specs", as described by the article.
If a good project manager sits down with the customer and describes back all of the functionality that the customer wants, then there will not be an issue. However, project management is usually lacking with follow-up and follow-through for more complex projects, and programmers end up asking the Project Manager what the customer wants, and the Project Manager answers as if they know, but they are guessing.
I've done code enough to see that happen again and again. However, if the programmer talks directly to the customer, nothing will ever get done, because the programmer will ask far to many questions - confusing the customer in the process.
In conclusion, Maybe it's really a lack of compitent Project Management. Again, room for personal idiocy.
Honestly, most Dev shops don't have "code librarians" anymore. When they did - this was the person who would make sure that code didn't get duplicated. If a current function could do what needed to be done with very few changes, so be it.
What happened where I was - some people who were not well trained in the code base started re-creating a large number of functions that we already had, and did so in an otherwise incompatible way. Yes, this should have been caught by the team lead... Yes, this should have been caught by their boss -- However, it could have been avoided had they been given a very specific specification of what these folks were expected to do.
I don't care how new the programmer, few of us like having someone over our shoulders - so, most of us assumed that they were each learning about the project as a whole, as opposed to digging in and seeing how to impress everyone with quick output. Human nature prevails again.
That's why I was always fond of the pseudo-code spec. The lead, or they guy with the idea would check-out the appropriate pieces of code from the development stream, and fill in the pseudo-code with what they wanted done.
/** Expansion of Commentary to get point across: * Use.. int funcSpec(char *example) * -- NOTE: funcSpec() will have to be expanded to * allow for me getting this point across. */
... This really worked well, until a bunch of new people merely thought they knew what the pseudo-code meant - it was obvious to us long timers.
Specs!? Specs!? I don't need
no stinking specificiations!
I used to work in a very loose
development shop. The only specifications
that were ever written down were protocol
specs - and even those were often
"documented" in the form of a header
file.
I found some parts of this method
usefull in that the specs were often
written as as pseudo-code comments, and
the actual code would be filled in
later.
However, eventually the development
pool grew, and we got a few folks who
couldn't follow this method, and we
lost several weeks of work. After that
standardized specificiation paperwork
was produced for every project from
that point on.
Perhaps it's a lesson everyone will
eventually learn. Perhaps I'm being
an idiot.
I guess they, for one, now welcome their new Microsoft overlords. (I wish this were a joke). Oh well. Perhaps their servers will have the right price point, but I'm sure Dell, and Gateway will undercut them in the commodity markets, and IBM and HP will undercut them in the multi-CPU x86 server market.
So much for my sounding informed. I'll have to look into this, I may put Sun back on my Vendor list.
It would never work for several reasons. I'll explore two.
Sun's biggest competitors are IBM and Hewlett Packard. Apple computers use IBM PowerPC chips. --
It's the same reason that Burger King restraunts started selling Coca-Cola products when Pepsi purchased Taco-Bell and KFC... Buying from your competition is bad business.
Apple is a desktop provider first. Apple sells servers as well, but only because of the demands for such hardware from companies that have standardized on Macintosh. Sun is a server company first, they have never had the capability of dealing with the commodity business of desktop hardware. The priorities of these two extremely different companies would never mesh. Thus the Culture would always run amok with the competing priorities.
Sun is loosing to cheap computers... Linux computers. Sun has been shipping X86 computers for several years now. Starting about 8 years ago, Sun started shipping SPARC systems with PCI backbones (so PC compatible components could be utilized).
While Sun's competition all sell Windows as well as UNIX and Linux servers, Sun has refused to play in the Windows game. Sun was never big enough to compete directly with the ranks of IBM (AIX) and Hewlett Packard (HP/UX) on both the UNIX and Windows front.
Sun started as a specialist UNIX based Hardware vendor. A great majority of Sun's popularity thoughout the 1990s was directly attributable to the UNIX specialist hardware at a fair price. Specifically their small-business and department entry-level servers.
Pound for pound Sun Hardware is still cheaper than HP/UX PA/RISC hardware or IBM AIX Power/PowerPC hardware. HP/UX and AIX are also at risk, but HP and IBM have more than ample funds to cater to selling extrememly inexpensive Linux based servers. Blue and Brown both are willing to relegate UNIX to Large Scale installations only. Sun's 'entry class UNIX servers', once thier bread and butter, have now been outclassed by Powerful Linux solutions.
Smartly Sun now also sells Linux based servers - but their servers do not have the assumed Windows/Linux flexability of the commodity hardware servers sold by the competition.
My point is - Sun is dying because of IT purchasing agents, like me, who are not willing to buy vendor lock (lock into Linux / lock into Windows). Because Sun isn't prepared to play in Windows, they suffer.
I agree that Windows has something to do with it, but I don't think it's as direct as you propose.
This simply a case for the Federal Trade Commission. The inclusion
of CAN-SPAM law into the criminal charges is
merely an after thought (as I mentioned before):
From the Article:
Investigators said they consulted Dr. Michael D. Jensen,
a medical professor at the Mayo Medical School,
who confirmed that ingredients in the weight-loss product
sold in the disputed e-mails wouldn't work.
By this, as well as the FTC's involvement
(see FTC link above), this is a simple case of
fraud. The CAN SPAM sentancing guidelines provide for tacking an
extra couple of years to the sentance in such
a case.
The addition to CAN-SPAM in this case will
only serve to attract more attention to the problem of
E-mail fraud. My previous statement remains,
"anextra 1 to 3 years tacked onto a
felony conviction is nothingcompared to the
sentance that is already being faced."
The problem with this comparison is that you are looking under the word, "insurance" - Probably "Insurance, Autos". There is no question that the word, "Insurance", is open subject for AdWords. On the otherhand if you have a whitepages listing where AXA's listing points to a phone number and address for Traveller's insurance, then you have a valid argument
Except, in that case, the phone book publishing company would be sued
"I'm sick of lawsuits against them for indexing public sites."
This specific case has nothing to do with simple indexing functions, but I think you knew that. This case is about money.
"...We have been paid to show you these ads when you typed that word..."
The minute Google is making money off of the sale of a term, this is where their liability starts. Everything else is the nature of search engine technology. If you still disagree, then there is nothing I can say to convince you otherwise.
The answer is no... in the scenario you mention, no. Basically they are a search engine, and related terms is a search engine thing. However, the question, in my own not so humble opinion is not about searches, but advertising.
If Google honestly returns search links because of related words (found via some tree-search profiling of AXA), then that's an honest use of search engine technology. I think we agree here.
However to specifically sell advertisements to a company based on the AdWord availability of a company's name to that company's competitors is to deliberately dilute the trademark. Consider Chrystler. If I sell roses, and I buy the AdWord for Chrystler, fine. Chryster was a type of rose, long before it became a car-related trademark. However, if I sell cars, then this is bad. I'm diluting the trademark. Google is considered authoritative by many people. I automatically assume that when I find the word Ford on a Mazda web-site that the two companies are affiliated (they are). I automatically assume that when I get search results from Google the results I get have something to do with my term.
Ignoring ads - a search for AXA does not return competitors, so why do the ads return competitors? Because my search term triggered specific purchased results. Not because Google thinks they might be handy. That's where your argument and my argument become about two different things, no?
Yes and No - basic communication is something that deaf people need to do regardless of origination. If a deaf person is at a public library terminal (not unlikely), how are they to provide thier 'credentials'? Userid/password over a library network is a bad thing, and many library terminals won't allow SSL connections because of security issues (defeats content filters).
While relay is anonymous (just as anonymous as a person-to-person call) - that means just like any other person to person call, the local police can still order a search warrant for your IP address. Then the Police will still knock on your door in short order, and you will be arrested (after your computer has been searched for evidence of tampering/open relay, etc).
So, you can talk-the-talk, but if you did something like this and got away with it - you were going through at least one more layer of obfuscation. Otherwise, you probably aren't at your computer anymore to get this reply... (Hi officer - I tried to tell him he's being stupid).
How about the other side, and the reason why the original case was overturned...
It's reasonable to assume that use of the words "direct assurance" would be naturally constructed by anyone who sells an assurance product directly to customers (as opposed to exclusively over broker networks). This is conterpointed to a famous US trademark, "Built Ford Tough". Here it's not reasonable to assume Chevrolet would naturally contruct this phrase about their automobiles.
My original assertion (first post) - I think they have a good chance of losing because of the term AXA, not because of the term, 'Direct Assurance'.
The terms sold were "AXA" and "Direct Assurance". The second term is similar in makeup of the previous overturned lawsuit. It's just a term that could be used in common speach about your assurance (insurance/indemnity) product. However, "AXA" is not a common use term, thus selling it to someone whom doesn't own that trademark probably qualifies as negligence.
If these AdWord links were created coincidentally by finding the word 'assurance', 'insurance' or 'indemnity' in the search results text, then this would likely have no standing in court. However, it appears to be the assertion of AXA (the company) that their trademarks were sold to AXA's direct competitors.
Again read my linked post for more background on the context of THIS post.
If I search Google for "Chevrolet" - I find links to exactly what I'm searching for. In the 'AdWords' sections, I see affiliate links (these are places where I can buy a Chevrolet automobile, although they are not exclusive Chevy dealerships). I do NOT find any links to Ford, Lincoln, Mitsubishi or Mazda.
The use of the 'AdWord', Chevrolet, by anyone besides Chevrolet or GM is questionable, however - the places that purchased those AdWords have the
right to use the name of the product they are selling, "Chevrolet".
If there is some inherent need for me to find out about something other than Chevrolet, then I should rightly be searching, car, automobile or auto (the service I want, not a specific brand).
Similarly, there wouldn't have been a question had these ads been purchased by companies that had a fair-use right to use the term, AXA. Such as an Independant Insurance Broker that sells AXA as one choice among many.
The question comes down to how much research should Google be forced to do before taking money to sell me an 'AdWord'? I think everyone is in agreement that the use of dictionary words (at least independant words) should not require research. However, if a word is not in the dictionary, the requirement for 'proof of trademark' or proof of fair-use should be
present.
The fact that Google seems to do no such search, when it is expected of them (this expectancy was established by their initial loss in the Travel Agency case).
I can see why the telcos didn't put these protections in place from the beginning, though...
Remember those pesky laws that guarantee confidentiality of those whom are relegated to using relay services as their only means of communication with non-TTY enabled businesses. Those laws (of course) were written for TTY/vox relay and not Internet/vox relay. That's why the blocking has to be done PRIOR to 'connect'. They'll find open proxies and come from US based addresses soon enough (no disagreement with you there).
Google posts paid advertising links (on the sides and above normal search results) always using a different background color, and specifically noting that those results are "sponsored links".
The fact that Google specifically separates sponsored links from it's normal search results is one of the reasons why Google has as high a popularity as it does.
About this lawsuit
The AXA company is suing Google for selling both the trademarked term, "Direct Assurance" and the companies non-dictionary name, "AXA".
Google sold the non-dictionary term AXA to competitors of AXA. This has nothing to do with standard search results, and everything to do with advertising. If AXA were a dictionary word in English or French then there's a decent chance that Google would win the case (like the last case).
While I personally feel there is no validity to a lawsuit over selling a trademarked term made of 'dictionary' words, I see potential for liability where you are selling terms that are not otherwise found in the dictionary.
If the customer has a million expections, but your Lead or Project Manager has not told the customer what to expect from their current "official" requirements, then you will have a disappointed customer. However, if you let the customer know, right from the start that the project will do exactly what they ask, and no more - then "extras" that were designed in through savvy programming, code re-use - or interface standarization, etc. will now be beyond the customer's expectations.
On the other hand, when a customer says, I want it to be like Excel, the Project Manager's first words should be, "why can't you use Excel?" - as opposed to "Sure, what about Excel do you want us to emulate?".
If a good project manager sits down with the customer and describes back all of the functionality that the customer wants, then there will not be an issue. However, project management is usually lacking with follow-up and follow-through for more complex projects, and programmers end up asking the Project Manager what the customer wants, and the Project Manager answers as if they know, but they are guessing.
I've done code enough to see that happen again and again. However, if the programmer talks directly to the customer, nothing will ever get done, because the programmer will ask far to many questions - confusing the customer in the process.
In conclusion, Maybe it's really a lack of compitent Project Management. Again, room for personal idiocy.
Honestly, most Dev shops don't have "code librarians" anymore. When they did - this was the person who would make sure that code didn't get duplicated. If a current function could do what needed to be done with very few changes, so be it.
What happened where I was - some people who were not well trained in the code base started re-creating a large number of functions that we already had, and did so in an otherwise incompatible way. Yes, this should have been caught by the team lead... Yes, this should have been caught by their boss -- However, it could have been avoided had they been given a very specific specification of what these folks were expected to do.
I don't care how new the programmer, few of us like having someone over our shoulders - so, most of us assumed that they were each learning about the project as a whole, as opposed to digging in and seeing how to impress everyone with quick output. Human nature prevails again.
Specs!? Specs!? I don't need no stinking specificiations!
I used to work in a very loose development shop. The only specifications that were ever written down were protocol specs - and even those were often "documented" in the form of a header file.
I found some parts of this method usefull in that the specs were often written as as pseudo-code comments, and the actual code would be filled in later.
However, eventually the development pool grew, and we got a few folks who couldn't follow this method, and we lost several weeks of work. After that standardized specificiation paperwork was produced for every project from that point on.
Perhaps it's a lesson everyone will eventually learn. Perhaps I'm being an idiot.
So much for my sounding informed. I'll have to look into this, I may put Sun back on my Vendor list.
Sun's biggest competitors are IBM and Hewlett Packard. Apple computers use IBM PowerPC chips. -- It's the same reason that Burger King restraunts started selling Coca-Cola products when Pepsi purchased Taco-Bell and KFC... Buying from your competition is bad business.
Apple is a desktop provider first. Apple sells servers as well, but only because of the demands for such hardware from companies that have standardized on Macintosh. Sun is a server company first, they have never had the capability of dealing with the commodity business of desktop hardware. The priorities of these two extremely different companies would never mesh. Thus the Culture would always run amok with the competing priorities.
While Sun's competition all sell Windows as well as UNIX and Linux servers, Sun has refused to play in the Windows game. Sun was never big enough to compete directly with the ranks of IBM (AIX) and Hewlett Packard (HP/UX) on both the UNIX and Windows front.
Sun started as a specialist UNIX based Hardware vendor. A great majority of Sun's popularity thoughout the 1990s was directly attributable to the UNIX specialist hardware at a fair price. Specifically their small-business and department entry-level servers.
Pound for pound Sun Hardware is still cheaper than HP/UX PA/RISC hardware or IBM AIX Power/PowerPC hardware. HP/UX and AIX are also at risk, but HP and IBM have more than ample funds to cater to selling extrememly inexpensive Linux based servers. Blue and Brown both are willing to relegate UNIX to Large Scale installations only. Sun's 'entry class UNIX servers', once thier bread and butter, have now been outclassed by Powerful Linux solutions.
Smartly Sun now also sells Linux based servers - but their servers do not have the assumed Windows/Linux flexability of the commodity hardware servers sold by the competition.
My point is - Sun is dying because of IT purchasing agents, like me, who are not willing to buy vendor lock (lock into Linux / lock into Windows). Because Sun isn't prepared to play in Windows, they suffer.
I agree that Windows has something to do with it, but I don't think it's as direct as you propose.
A joint project of consumer protection agencies from 17 nations:
http://www.econsumer.gov/english/
The really sad part is that it took 10,000 complaints, before anything was done about the fraud.
I don't believe that the FTC simply waited for CAN-SPAM's extra three years of prison to come into effect before deciding to look into the fraud.
So, 10,000 complaints, and they'll look into convicting someone. Just remember, every complaint counts, so start reporting your fraudulent SPAMs.
This simply a case for the Federal Trade Commission. The inclusion of CAN-SPAM law into the criminal charges is merely an after thought (as I mentioned before):
From the Article:
By this, as well as the FTC's involvement (see FTC link above), this is a simple case of fraud. The CAN SPAM sentancing guidelines provide for tacking an extra couple of years to the sentance in such a case.
The addition to CAN-SPAM in this case will only serve to attract more attention to the problem of E-mail fraud. My previous statement remains, "an extra 1 to 3 years tacked onto a felony conviction is nothing compared to the sentance that is already being faced."
Except, in that case, the phone book publishing company would be sued
The minute Google is making money off of the sale of a term, this is where their liability starts. Everything else is the nature of search engine technology. If you still disagree, then there is nothing I can say to convince you otherwise.
If Google honestly returns search links because of related words (found via some tree-search profiling of AXA), then that's an honest use of search engine technology. I think we agree here.
However to specifically sell advertisements to a company based on the AdWord availability of a company's name to that company's competitors is to deliberately dilute the trademark. Consider Chrystler. If I sell roses, and I buy the AdWord for Chrystler, fine. Chryster was a type of rose, long before it became a car-related trademark. However, if I sell cars, then this is bad. I'm diluting the trademark. Google is considered authoritative by many people. I automatically assume that when I find the word Ford on a Mazda web-site that the two companies are affiliated (they are). I automatically assume that when I get search results from Google the results I get have something to do with my term.
Ignoring ads - a search for AXA does not return competitors, so why do the ads return competitors? Because my search term triggered specific purchased results. Not because Google thinks they might be handy. That's where your argument and my argument become about two different things, no?
While relay is anonymous (just as anonymous as a person-to-person call) - that means just like any other person to person call, the local police can still order a search warrant for your IP address. Then the Police will still knock on your door in short order, and you will be arrested (after your computer has been searched for evidence of tampering/open relay, etc).
So, you can talk-the-talk, but if you did something like this and got away with it - you were going through at least one more layer of obfuscation. Otherwise, you probably aren't at your computer anymore to get this reply... (Hi officer - I tried to tell him he's being stupid).
Good point, they are also no longer found above normal search results. They are relegated to a side bar.
It's reasonable to assume that use of the words "direct assurance" would be naturally constructed by anyone who sells an assurance product directly to customers (as opposed to exclusively over broker networks). This is conterpointed to a famous US trademark, "Built Ford Tough". Here it's not reasonable to assume Chevrolet would naturally contruct this phrase about their automobiles.
My original assertion (first post) - I think they have a good chance of losing because of the term AXA, not because of the term, 'Direct Assurance'.
The terms sold were "AXA" and "Direct Assurance". The second term is similar in makeup of the previous overturned lawsuit. It's just a term that could be used in common speach about your assurance (insurance/indemnity) product. However, "AXA" is not a common use term, thus selling it to someone whom doesn't own that trademark probably qualifies as negligence.
If these AdWord links were created coincidentally by finding the word 'assurance', 'insurance' or 'indemnity' in the search results text, then this would likely have no standing in court. However, it appears to be the assertion of AXA (the company) that their trademarks were sold to AXA's direct competitors.
Again read my linked post for more background on the context of THIS post.
If I search Google for "Chevrolet" - I find links to exactly what I'm searching for. In the 'AdWords' sections, I see affiliate links (these are places where I can buy a Chevrolet automobile, although they are not exclusive Chevy dealerships). I do NOT find any links to Ford, Lincoln, Mitsubishi or Mazda.
The use of the 'AdWord', Chevrolet, by anyone besides Chevrolet or GM is questionable, however - the places that purchased those AdWords have the right to use the name of the product they are selling, "Chevrolet".
If there is some inherent need for me to find out about something other than Chevrolet, then I should rightly be searching, car, automobile or auto (the service I want, not a specific brand).
Similarly, there wouldn't have been a question had these ads been purchased by companies that had a fair-use right to use the term, AXA. Such as an Independant Insurance Broker that sells AXA as one choice among many.
The question comes down to how much research should Google be forced to do before taking money to sell me an 'AdWord'? I think everyone is in agreement that the use of dictionary words (at least independant words) should not require research. However, if a word is not in the dictionary, the requirement for 'proof of trademark' or proof of fair-use should be present.
The fact that Google seems to do no such search, when it is expected of them (this expectancy was established by their initial loss in the Travel Agency case).
Remember those pesky laws that guarantee confidentiality of those whom are relegated to using relay services as their only means of communication with non-TTY enabled businesses. Those laws (of course) were written for TTY/vox relay and not Internet/vox relay. That's why the blocking has to be done PRIOR to 'connect'. They'll find open proxies and come from US based addresses soon enough (no disagreement with you there).
No.
Not search... Adverts (explanation at linked post).
Not to be a smartass myself, but isn't that counter-intuitive?
Google posts paid advertising links (on the sides and above normal search results) always using a different background color, and specifically noting that those results are "sponsored links".
The fact that Google specifically separates sponsored links from it's normal search results is one of the reasons why Google has as high a popularity as it does.
About this lawsuit The AXA company is suing Google for selling both the trademarked term, "Direct Assurance" and the companies non-dictionary name, "AXA".
Google sold the non-dictionary term AXA to competitors of AXA. This has nothing to do with standard search results, and everything to do with advertising. If AXA were a dictionary word in English or French then there's a decent chance that Google would win the case (like the last case).
While I personally feel there is no validity to a lawsuit over selling a trademarked term made of 'dictionary' words, I see potential for liability where you are selling terms that are not otherwise found in the dictionary.
The Scrabble dictionary is a sub-set of the Merriam-Webster dictionary - which doesn't list axa as a word.