Related
how would you handle a client who wants you to implement a website layout that looks horrible and is wrong in many many ways, when they absolutely think it is great, really "different" and cool and since you are a programmer, you don't know anything about design.
i have tried arguing, reasoning and not caring, but it pains me physically to think that i should put that online... any tips or experiences would be great! thanks.
update: things are even a bit more complicated, since it is not just any client but a business partner with a great business idea, that i want to be part of...
Craigslist.com is one of the most visited websites on the planet. Yet its UI is appalling by most modern aesthetics.
This isn't a technical issue, but a business issue. You need to sit down with your business partner and put forward your point of view convincingly. If you're going to work with her in the long term, then you both need to find a way of resolving issues and coming to a compromise. Look at this dispute as a warning sign about the business relationship.
I've some experience with what you describe. I usually try to convince them their design is not as good as they think. Things like usability, navigational structure can help you in the argument. I've noticed that showing some heatmaps of how people look at websites can have a nice result. "I never looked at it that way"
If they however insist on the bad design, you have roughly 3 options:
Politely tell them to find somebody else to create the ugly site for them.
Make them sign a document that states that you strongly advised against the design and that they cannot hold you responsible if they get bad results or comments
Bow your head and build it.
Option 1 can hurt your reputation just as bad as option 3.
Option 2 sometimes convinces the client that they might be wrong after all as it is now written on an official looking piece of paper they have to sign. But a least ensures you can work with a clear conscience; you warned them, they wanted it anyway.
Good luck :)
He who pays the piper calls the tune.
Depends how much the coin matters.
Managing difficult clients is something you need to come to terms with, as a freelancer, or any sort of sufficiently experience professional.
If you don't like the design, you can have a simple thought: Do I need this client? If not, drop them. If you do, then just accept that you don't always get things your way, and deal with it.
If you don't want your name attached to the work, you can easily come to that compromise.
Sometimes you need to make moral choices about clients as well; in this case you just have a subjective art choice; I think it is easy enough :)
I have had some cases as you describe. Just keep in mind that you are creating something for your client, it's the client that will work everyday with the application and it's the client that need to be happy with it, not you :)
There have been a lot of answers that boil down to:
Just do it for the $$$
Do a mock up of something better
Run a usability test
Run like hell (but politely)
All of these assume that:
The design really is bad
You are objectivly approaching this project
Please don't hear what I'm not saying: I am not saying your premise is wrong.
First, I am saying its worth considering that it may not be that bad. There are a lot of very successful sites out there that drive designers nuts. If it doesn't satisfy a need, it won't matter how well its done.
If you want to be a part of this than you need to look at the business plan first, and see if its valid, and if the site will fulfill it. If either one of those is a no-go, than fix those problems first.
Second, ask your associate if (s)he's considered other designs. Ask for the sites they used to come up with what they want, and ask what else they've considered.
If they give you something, look at what makes those good/bad and see if between the two of you you can come to a better design.
If they can't, then tell them that with some work there may be something better and work together to create 3 or 4 mock ups. Then whip out the usabilty test. Even if you've done them before, I highly recommend reading what Jakob Nielsen has to say about it over at http://www.useit.com/alertbox/
Since this seems to be a business partner, just doing it for the money and/or running like hell doesn't seem to be an option. Working through this with a little more give and take may help, but if you can't come to an agreement, then you probably ought to leave.
Ask users that match targeted audience
Why don't you create a mockup of a particular part of this app/site and try asking a few people that represent the persona of the product. The targeted audience. Give them two possible choices and let users decide what will make business value instead of you or the client.
Be careful since the first thing I would do when coming to such a website is to look who's the webmaster that produced that site. And then if I would see your logo below it wouldn't impress me. It's not for your good reputation.
So as a professional in that area, I would try to discuss the design with your client, offering him your knowledge about good website design, since that may be also part of the service you're offering.
If you really need the money, just do what he wants and take the cash. Avoid your name appearing on the site anywhere.
If you have other work lined up, tell the client you think he would be better off with a different designer that can meet his needs and say goodbye.
My experience of this kind of client tells me they are a royal pain the arse, with endless tweaks and adjustments to the design. Get out while you can.
Do it. In your own time do your own version - as you want it to be great, which you do as you have a stake in it (you want to be part of it). Show them the better idea. Make them buy into it by making them feel part of it, not that you have done it behind thier back. the idea just came to me and I done it. If they don't like it tough – you could never have won. However they might just be impressed at your effort and/or initiative.
I'd say do it but put nothing identifying you or your company on it, and keep it the hell away from your portfolio. Also have very explicit conditions around ongoing support for it.
Maybe you could bring in a third party, someone whose opinion on design and suggestions for improvement your business partner would respect -- maybe a graphic designer or a web usability expert. That way, you might be able to salvage this business opportunity without alienating your business partner.
I agree with others. If you don't need the work than politely decline. If you do, release what the client wants and make them pay for every tweak after launch once they realise the design sucks.
Perform usability tests. Create a mockup that's fairly close and get people involved from the target audience. If they are a designer then they should understand that this is a sensible approach. Be careful to introduce it as best in both your interests.
The key is to get independent feedback. That keeps you sweet with your business partner and you also get a good design.
If it's a bad design and it's being pushed, then it's someone's "baby" and you can't touch it.
It won't matter how good your alternative is. It won't matter if you can point to the exact same site in, "Web Pages that Suck." It won't matter if senior executives quietly say, "Wow - I really like the alternative - it makes us look Fortune 500!" It won't matter if you bring surveys, focus groups, or if Jesus, Himself, shines the light of truth on your alternative and blesses it: you'll be branded as a, "non-team player," and the cruddy site will STILL be posted.
Then, in 18 months, after you're gone and the three people who were hired to replace you EVENTUALLY cough up a site with minor, almost embarrassing, changes that actually make the site resemble an ad for adult incontinence products, you can come back to this post and say, "Hey - thanks. You... were right."
I want to add an Link to my question:
Storing Password in Databases in plain text vs Customer Needs
In some cases it is the same issue. There are customer needs that are not acceptable. the answer provided in that question maybe help you find a way around that problem.
I think I've worked with this person before, when a university website was being designed by committee. We had two people come up with designs, and the initial vote went 12 to 1 ... the one who was ahead was done by a professor of commercial art, who couldn't care less if you didn't like his design. The other one, though ... she had to come out and defend every little aspect of her design. The revote was 1 to 12, as I refused to change my vote.
Luckily, three of the people from the graphics department came up with a new design, and presented it at the next meeting, and everyone agreed it was better, so we were able to torpedo the blinking splash screen and George Washington's hair design.
Anyway, the point is -- you have to find out why she prefers her design, and then come up with something that takes each of those points, but doesn't suck. Unfortunately, it might take someone with design experience to manage to put it all together -- but if you're planning this to be a business venture, it might be worth spending some money on.
Here's my suggestions:
Why is the design bad? Make sure you understand why before you get into this conversation. Remember, there is some business goal behind having a website. Understand that, and use it as your point. If you don't know what the goal is, ask. If they don't know what the goal is, help them figure it out.
Offer alternatives. Point out the positives and negatives, and help them understand what the tradeoffs are.
Mockups and tests. If you can, mock up the alternative, and let them see the differences. Get potential users to try them out if possible. If not, at least have the customer use the mocked-up website as an actual customer, trying to fulfill an actual scenario.
Good design is the design that will meet the stated business goals of the customer (assuming that this is a business website).
Also, understand what your job is. Is your job to help them solve a business problem, or to implement a specific solution they have in mind? Understanding their expectations of you may help significantly.
I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For instance, customers that we're creating web sites for, request things like:
all links should open in a new window
put custom 'Back' button on every
page while there is a working
browser's equivalent
make some part of the text blinking etc.
Of course I tell them it's wrong, but is there some nice list of bad things to have from a respected source that I can point them to?
Become that respected source. Seriously: if your clients are showing reluctance to take your advice directly, compose documents that illustrate good and bad user interface design and publish it on your website. You gain three things from this:
You become more knowledgeable about the why of bad and good design. Having to think through something to compose it into a document is more helpful than many give it credit for.
If this is publicly published, you probably will get feedback about your ideas. Throw away the bad suggestions and integrate the good, and you become better at your craft.
You have the source for these discussions in a presentable format, yet you retain all your personal branding. If you include examples and demos of the good and bad, most people can see why you advocate for your ideas.
EDIT: epotter is dead on as far as the "buck stops here" aspect of interacting with a client. If your documents can show why irritating a user is a loss of revenue in the long run, it is unlikely you will have much push-back. On the other hand, if your personal preferences includes UI designs that don't help with retention... stop doing that. (I recall the days of "CSS Only, No Tables" designers before CSS had matured: they insisted on forcing their designs on clients, even though in some browsers they didn't render well. While a cause is admirable, you work for the client not a cause.)
Always try and show them how it will cost them money. For example, if they are going to do something that annoys the user, they will have less traffic which will lead to less revenue.
For better or worse, dollars always speak the loudest.
First, don't tell them it's wrong.
They may take it personally.
Instead, understand the need they are trying to fill, then suggest alternatives that don't include the bad behavior. Mock all the alternatives up and point out the good and bad of each one. Let them choose. As long as you have a good alternative, and sufficiently pointed out the faults of the bad implementation, then they generally come around to your point of view.
In other words, act like a designer. When a customer says, "I want green text on a red background," you don't immediately tell them that 10% of the world's males cannot read that, you first need to understand why. "Well, it's Christmas," then you can suggest alternate themes to give the site a festive feel without the design error. As long as the mockups you suggest are better than theirs then they will generally acquiesce.
Not because they made an error, but because you saw their real need and improved on their idea.
If they're adamant after that, though, do the work - don't spend your time trying to convince them the error of their design sense, it's a waste of resources.
Educate them over the long term, but if it takes you an hour to convince them not to make a change, that's one hour you could have spent improving your relationship with customers who treat you as designers rather than web-monkeys.
-Adam
I've had to play a semi-sales role at time with web projects and I have to stress how important it is to keep the customer happy.
Nevertheless, I completely agree with you that you are obligated to say something in the name of giving them what they want. I always found that the best approach is to start by agreeing with them (in principal at least). You could say,
"I completely agree with you that this
text is very important to your users.
Many testers that I've worked with
have strongly preferred using this
font/graphic/color to call out
critical text. Unfortunately, some
users associate flashing text with ads
and avoid it"
I find that this approach lets them know that you
Understand what they want
Appreciate their motivations and suggestions
Only want to help
One last word of advice, if after the gentle nudging, they don't get the point, consider doing two quick mock-ups. (their idea and yours). If that doesn't work, then just give them what they want. In the end, they pays the bills and if they really want an ugly site (assuming you can't afford to turn away business on aesthetic grounds) just give them the site.
Good luck and take deep breaths!
Jakob Nielsen's Alertbox has been an invaluable source of common-sense usability advice for me for many years. Here's something he wrote way back in 1996 that still applies today:
The BACK feature is an absolutely
essential safety net that gives users
the confidence to navigate freely in
the knowledge that they can always get
back to firm ground. We have known
from some of the earliest studies of
user navigation behaviorthat BACK is
the second-most used navigation
feature in Web browsers (after the
simple "click on a link to follow it"
action). Thus, breaking the BACK
button is no less than a usability
catastrophe.
And here are the first two of his Top Ten Web Design Mistakes of 1999:
Breaking or Slowing Down the Back Button
The Back button is the lifeline
of the Web user and the second-most
used navigation feature (after
following hypertext links). Users
happily know that they can try
anything on the Web and always be
saved by a click or two on Back to
return them to familiar territory.
Except, of course, for those sites
that break Back by committing one of
these design sins:
opening a new browser window (see mistake #2)
using an immediate redirect: every time the user clicks Back, the
browser returns to a page that bounces the user forward to the undesired location
prevents caching such that the Back navigation requires a fresh trip
to the server; all hypertext navigation should be sub-second and
this goes double for backtracking
Opening New Browser Windows
Opening up new browser windows is like a
vacuum cleaner sales person who starts
a visit by emptying an ash tray on the
customer's carpet. Don't pollute my
screen with any more windows, thanks
(particularly since current operating
systems have miserable window
management). If I want a new window, I
will open it myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
These aren't crazy newfangled ideas, they're decade-old guidelines based on hard research. You'd need a really, really, really good excuse to repeat a decade-old mistake.
Find examples of actual pages that do this and show them. Here's a good place to find some.
If you show them the examples, and instead of being awed by the suckyness and changing their minds, the clients say, "Yeah! That's exactly what I want!", then make them sign a nondisclosure contract saying they'll never tell anyone who designed their web site. :)
You have to explain "why". It's not enough to tell them something is "wrong" (and in these cases, it's not so much "wrong" as it is a "bad idea")
Most people respond well to logic and reason. If you can make a reasoned argument for why doing something a certain way is a bad idea, they'll usually bow down to your experience and knowledge.
useit.com is an excellent resource for usability arguments
but you're probably wasting your time. Either do it their way ("the customer is always right") or walk away - arguing is unlikely to improve the situation unless you can demonstrate a significant monetary gain from not doing it their way, which you probably cannot do given the issues you listed.
if your name will be on the site, i'd politely walk away
Show them some articles on sites like http://useit.com which has some empirical studies on how adherence to web standard practices increases usability and so therefore user satisfaction and so therefore profit.
Ask them what results they're after. "Have all links open in a new window" is a statement of solution. Solutions are your job, the client's job is to state objectives.
Start with this: "Oh, you'd like links to open in a new window. Tell me more about why you want that - I'd like to explore with you whether there are alternate ways of getting the same results."
Perhaps continue with this: "Also, I might point your attention to other consequences of opening all links in a new window - consequences you might not have considered, and which perhaps you wouldn't like."
Suggested reading: Dale Emery's articles on resistance.
At the simplest, try to explain them each of it in a user understandable manner.
e.g. Blinking text is an old style thing not supported by all browsers
Not sure why "back" can be a problem. But put your viewpoint.
It's always convincing if you demonstrate to the user that his design is unconventional or wrong by showing a list of very well known websites that he would "respect" and pointing out how they don't do X. Your customer will probably want his site to be like the big players' web sites.
If he still insists that his weird design makes sense you could say: "yes, I agree that sounds like a good idea in theory, but the fact is that users are simply unaccustomed to X and would walk away from your website if it diverges too widely from the standard way of doing things".
IOW, when all else fails, use fear.
You can lead a horse to water, but you can't make it drink.
With customers (of any type), the best you can do is inform them of their choices, and why they are not the best ones and then leave it. If it's really bad, require sign-off stating that they find that design acceptable. Do you want to be 'right' or do you want to get something into the customer's hands that works?
If it completely impedes a working solution, then (and only then) should you stand on principle, but beware you have very few (if any) of these 'stands', so use them wisely. Be prepared to walk away.
Paul.
Unless there is a compelling business case NOT to do it (and I'm not sure this is the case with any of your examples) then if the customer is adamant DO IT! They are paying for it after all. They can always find someone else who will do it if you won't!
While designing my site I am constantly faced with the issue of whether its ok to TAKE ideas and designs from other sites. In some cases there is no distinction in certain aspects. Is there anything ethically wrong with this? Is this expected in the design programming community?
Depends on how much you 'steal'.
Code
If you're ripping off the whole design, then its a bit dodgy. If you like (for example) the Stack Overflow concept of voting up stuff, then steal the concept and use it in a different manner. If you want to know how say the orange highlighting of the up-voted items works, then look at the code. But don't do both and steal both the concept and the design, you'll just create a clone.
Due to the way different web browsers treat CSS and the like, there are often only a very few limited ways to do a particular thing (3-column layouts, etc.). It seems fair enough to blatantly copy in these cases where there is a common way of doing things. Where its something unique, and there's many ways of doing it, it seems a bit more off to blatantly copy.
Graphics
Ripping off graphics - not so okay. Images have been around a lot longer than code so copyright law, etc. probably suits them better. If nothing else you have to contend with possible watermarks or other metadata to identify the original source. It's very easy to check for image stealing, less so for code within a larger block.
I'm a coder, not a designer so what I tend to do is borrow graphics that I like just while mocking up my web-app for internal use. Does that seem fair? I'll change them for newly-designed or paid-for ones before going live. At least that's the idea, though it could be far too easy to forget and use them by accident.
That's the way it works in the newspaper world (well it used to, not sure now with the advent of this there Internet thang): You download as many graphics as you can bother waiting to come over your 57.6k modem; you only pay for the ones you actually publish.
Oh, this is a hard question.
On the one hand stealing is wrong, on the other hand you are obliged to save you employer money by solving a task quickly.
My only advice is:
If it feels wrong in your gut, you probably stole too much.
I think most designers and developers draw a distinction between 'creative inspiration' derived from someone else's work and blatant plagiarism.
I wouldn't think twice about peeking under the hood to see how someone had done a particularly nifty javascript effect, or implemented a tricky piece of css elegantly, but I'd find it distasteful to blatantly cut and paste that same code for use in my own development.
I'm not learning anything by just grabbing and reusing - although I think it's fairly standard to have the same code to hand as a rough scaffold from which to explore my own way of implementation. I think that's the way a lot of people work.
I am a web developer, not a designer. As such, I have a sense of taste, but not the ability to come up with something wholly on my own. As a matter of ethics, everything commercial or with the expectation of serious traffic that I do, I will hire a designer. They need to eat too, and there is something wrong with making money off of others work and not compensating them for it.
If it is small, personal, or an internal throwaway type thing, I will rip off things like color scheme and/or layout. Technically you could say this is stealing, but I think of it more as "imitation being the sincerest form of flattery" thing. I don't feel that bad about it since there isn't really any money to be made in it.
I think its ok to steal ideas, but not to steal code.
This is how a lot of design is accomplished. Except it's obscured by lots of lifts, not a single wholesale lift.
Stealing resources (graphics, code) is not really OK if they're not specifically marked as free/open/creative-commons/etc. Stealing design and layout is a bit sketchy if you're just xeroxing the same layout using your own code -- using someone else's design as a starting point is one thing, but don't just recreate their design verbatim. Stealing snippets of code for specific bits of functionality is fine (IMHO) since even if you grabbed a reference manual to learn it from scratch you'd end up with the same thing. (Think: javascript for changing an button image on mouse-hover)
Having said all that, imitation is the sincerest form of flattery. Don't steal resources, but using other sites as "influence" should be OK. Or, if in doubt, ask the owner of the site you intend to use as reference/influence.
It's almost like everyone answering this question forgot what it was like to work with web pages between 1995 and 2002 or so. Stealing was a way of life for tons of designers during that period. The key was, and still is, to take only what you need, and to make sure that you understand it well enough to make it from scratch the next time. Who knows, you might improve something in the process.
There's an old saying I was once told: Good designers create. Great designers steal.
That said however, you should never blatantly rip off code if you can avoid it. Look at it, understand it, rewrite it (or improve it, if possible; even if it's only something like using what you find are better variable names) but never just copy and paste. Same goes for layouts; take the layout and modify it to suit your needs - it might end up looking similar (look at all of the Basecamp-style clones out there as far as UI goes) and that's no big deal at all; plenty of sites look similar. The key is to go into the situation looking for inspiration and not some code to yoink. If you can use the code as-is or with little modification then you really have no problems, but it shouldn't be your intention to find someone else's code and rip it off.
It's a sliding scale. Borrowing just an idea is one thing, if you're incorporating it into the rest of your existing design, not just wholesale copying an idea. Snagging a idea for a design element is fine, copying a whole design exactly is not. As you borrow more and more of a design, it gets into the not acceptable category. Copying directly is also another factor. If you see something you like and reimplement it for yourself, that is typically fine. But doing a direct copy of code, images, or css not so much.
For the most part, ideas are fine to take and implement. If people couldn't take existing ideas and expand them or re-implement them, we'd never have gotten out of the dark ages.
If you feel the need to steal code because you can't code HTML/CSS well or don't have an eye for design, steal from a place that explicitly permits you to use their design/code, like OSWD. In general, stealing HTML is fine, but ripping off CSS wholesale is a no-no. Just because you can easily view the CSS source doesn't mean that it's ok to just copy and paste it.
Don't steal graphics, period. Especially things like photos and logos and icons. If you need that sort of thing, purchase stock photography or take your own photos.
When in doubt, ask the owner of the site.
Stealing code or designs is immoral and in some cases illegal.
Taking inspiration or copying functionality is less of a problem. For example, at some point in time someone realized that putting a "Forgot Password?" link next to all login forms is a good idea, now everyone does it. It's not theft it's just replicating a good idea.
I'm not a web developer, but I might have some insight that will help as well. My team has created several applications that have served as the starting point for other applications delivered to various customers.
The successful derivatives were those in which the developers took the time to learn the architecture and why things were the way they were. They then took the more crusty parts and rewrote them and in general expanded and improved the architecture.
Invariably, when a team simply took the existing project and tried to 'brand it' or copy it for a customer without actually figuring out the systems, they either created poor implementations of the extensions or had the project fail outright.
I realize this is a bit off the main topic of the ethical issues address by others here just fine, but my bottom line is that pure theft usually costs you more time than it saves.
Whilst working on some generally horrible Javascript code this morning, I came across the following (in multiple places):
// make moveAmount negative
moveAmount = moveAmount - (moveAmount * 2);
I sit directly across from the guy that wrote this; he's been a developer here for seven years. I, on the other hand have just started, am pretty junior and don't claim to know jack.
Nevertheless it has got me wondering about the guy's contortions of simple logic after so many years developing software.
My question is what view others here might take of the overall competancy of a developer that wrote this (3 weeks ago), or does it even reflect at all?
Would anyone point out the convolution?
I, myself, work in constant dread that such judgements be made of me.
Simple solution: Show him the line of code and ask why he did it. It's an opportunity for both of you to learn something. Maybe there was a bug in a browser or some other issue (rounding comes to mind) so the code might break without this. Or he made a mistake. Either way, asking will clear this up.
And while you're right that other people will judge you from the code they see from you, that is not the only thing they take into consideration (and if it is, then you're working at the wrong place -- leave while you're still sane). They will also see when you're polite, curious, helpful.
These things count more than the code you write: Code can be fixed much more easily than angry co-workers.
Your example may be poor code, but I've seen worse (after all, there are circumstances where it will work; some code can't even say that). I think the question you're really asking is: is there any line of code so awful that it means the developer can be deemed incompetent on the basis of that one line?
I say no. I have two children who were terrible sleepers as babies. I've come to work with the flu. I've been at work in death-march mode where I've been working twenty hours in a row. In such circumstances anyone can write a terrible line of code. (This is why such circumstances should be avoided.)
Granted, I would hope I would spot the dreadful code later, and fix it.
Well it works so you would just look like a p**** if you told him that you dislike that code and probably rightly so :) Then again he might have done that code 7 years ago as the very first JavaScript he wrote, but seriously never judge someone from just ONE LINE of code.
Regarding the fear of judgement, relax. It's true, we're all going to be judged by someone at some point, whether it's some pointy-haired boss or maleveolent little upstart. The main thing to get to grips with, I think, is how to get something useful out of every such encounter.
Obviously, there are going to be people griping about things for the sake of it, but you'll also find many similar situations where there's something to be learned.
The suggestion above to start a dialogue with your co-worker is excellent; it may directly feed into just such an encounter, from which either, or both of you, may learn something important.
It's tempting to find one example and generalize about a developer, but unless he has a track record of this sort of nonsense, I would consider it an isolated incident. Simply ask him why he didn't write :
moveAmount = moveAmount * (-1)
this behavior is different from
mountAmount = -moveAmount in the case where 2*moveAmount may cause an overflow if moveAmount was big enough (like 2^32-1 for example).
I don't know if that was his intention though.
Since he wrote it 3 weeks ago, I would say he should be open to criticism for this line. It shows an immaturity that is really inexcusable after 7 years of working professionally.
If he would have at least done this:
moveAmount -= moveAmount * 2;
He would have gotten less flack. It at least shows that he's aware of the other operators and is making some effort to make things more readable.
I don't think that you can always judge people with one line, but the code can tell you so much about a person's aptitude that one line can tell a lot about a person.
I say it will depend on the swallow. If isolated, the line of code you've shown is something I would expect from an exhausted programmer, even if a very competent one. It is an example of something just not very clever and tired people do not so clever things. If, on the other hand that kind of code appears frequently then probably you're working with someone with a twisted mind.
Things that are obvious indications of a bad programmer are related to bad practices. Good programmers will not make huge methods. Even tired, they will try to keep their types loosely coupled. They will avoid exposing public fields instead of exposing them through accessors or properties. They will try inheritance and aggregation as forms of code reuse rather than repeatedly doing copy-paste... The list is long. Those are the kinds of swallows that lead me to almost instantly feel it is summer. :-)
If he wrote that when he was first beginning, he gets a pass. If he wrote that recently, he gets a thumbs down from me. The overall competency of the developer is definitely suspect.
Others are saying you can't judge a developer by one line of code, but I say it can certainly cast doubt upon his competence. I'm not suggesting you jump to conclusions, but that type of code is certainly evidence of a mediocre developer at best.
... and as for it being related to being overtired or stressed or whatever... the bottom line is that code quality is important. If he wrote a one-liner like this, what else may have been written that doesn't stand out so easily?