I'm in total agreement, but it all comes back to according to Hal and Steve, that to be a good programmer, the ability to spot, for example, usability issues in the requirements from the client is a necessity. This is idea stage stuff and should remain there, and get fixed with prototyping and wiremodels and all that stuff. I think having issues like this when the code is being written not only reflects badly on the process, it's inherently inefficient. So the coder should not have to use the right brain when coding, if the process is working correctly.
jon ----- Original Message ----- From: "Nick McClure" <[EMAIL PROTECTED]> To: "CF-Community" <[EMAIL PROTECTED]> Sent: Wednesday, March 27, 2002 4:15 PM Subject: Re: Conversations... > I am not saying you should speak directly to the client, but if you have > concerns, before, during, and after a project, then you should tell the > project manager. > > You shouldn't do something just because that is the way the client wants it > until you have voiced you concerns about it, then, of course, take the > money, and when they complain about it later, say I told you so. > > I like to think I am pretty good when it comes to what works and what > doesn't when it comes to design and interface. I usually tell people that I > don't like it. I don't have a problem telling the client their idea is bad, > or it should be changed. But in many places it is not the responsibility of > the programmer to do so. But the programmer, as a user who is testing the > site and understands more about it than anybody else, should voice > concerns, dislikes, and problems quickly so they can be resolved. > > Failure to do so can reflect poorly on the company and the client. ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
