Why do big sites use 'bad practices'? [closed]

Question

I often see articles, posts and comments something like:

• globals are bad in javascript
• script tags should be at bottom of page
• CSS should be in external files and at the top of page
• scripts should be in external files, not plain script-tags.
• etc.

I've looked up the HTML source of some big sites and have noticed that they have a lot of plain javascript and CSS inside HTML markup. JavaScript and HTML are note always obfuscated, and so on.

Answer 1

There are quite a few separate issues here.

1. What you see when you "view source" is not usually what they develop with. It's usually a compressed / optimised form generated from "source" code.
2. Claims about what is "best practice" are necessarily generic, and don't apply to all scenarios (especially if you're a big site and need specialised optimisation). These guidelines should be considered individually for each project.
3. Best practice, or even clean code, doesn't directly translate to return on investment. It may be nice to have consistent naming schemes, but is it worth the time developing and enforcing the scheme across 100s of developers?
4. Laziness, incompetence, or Friday nights.

Answer 2

Just because a site is big makes no guarantees about the quality of the code.

Have you ever viewed the source of Google's page? Is it pretty? No. Does it work? Yes!

Answer 3

Some possible reasons:

1. Some Web code simply isn't very big or complicated and it really makes no difference in maintainability whether it follows best practices or not, and it works fine the way it is.
2. Code is often written by inexperienced programmers, even on big, popular sites, and is never improved because it works fine the way it is.
3. Best practices change from time to time and it's seen as wasteful to spend time redoing your code just to adhere to the latest, when it works fine the way it is.
4. Adding new features is deemed more important than cleaning up old code, especially when, again, the old code works fine the way it is.

You may sense a recurring theme here. Rarely do programmers feel the need to fix what isn't broken.

Edit: If I were writing this now, more than two years later, I'd reword that final sentence to say "Rarely does management feel the need to fix what isn't broken." Most programmers love to revamp inelegant things, to the extent that they must sometimes be restrained by management in order to ship a product. I'd also throw in a mention of the concept of technical debt.