When developing websites it's easy to forget what you're actually trying to achieve.

The key purpose of a website is to build a portal for people to use. It's not to build a robust system that on paper and in the code looks immaculate, obviously that's the ideal situation but if that perfect system is not user friendly all the programming design patterns and database normalisation means nothing.

When building websites, and software, and anything, remember to keep in mind the people who will be using it. Spend more time thinking about what the user wants, and less time (not no time!) thinking about how the system behind the website should be put together.

Speaking from personal experience, I can say that I work a lot better when given a rough overview of what the site should do, and then the designs that have been put together from a designer; contrast that to how most developers work which is basing their work on documents that have been put together by document writers (clients, project managers, etc...). These documents serve their purpose, but sometimes they just don't work.

Generally when a project is being planned it goes like this: a salesman will get the client on board, an account handler will deal with the client and word up the requirements document, a project manager will put together the documentation on how the project should come together, a designer will put together how the project should look, then a developer will put the project together. This generally works nicely, however when there's absolute pigeon holing things start to break down. I take pride in being able to look at a design and say something doesn't look right, or that a client's suggestion is wrong, I also like to be able to take a design and make changes to it if necessary, and I like to be able to chop up Photoshop documents into websites. In my experience working in advertising agencies I found that to be useful, however in more corporate environments it's less appreciated.

We all have our jobs to do, but a little bit of cross-functional involvement.