I am constantly surprised by the level of quality programming @ large companies. Especially those who only seem to hire "The Best".

That should be a lesson in whether "the best" consider it important to every last thing 100% right, or to move quickly and maybe make a small number of mistakes along the way.

http://www.jwz.org/doc/worse-is-better.html

"It is slightly better to be simple than correct."

I would have said being correct AND simple would be ideal. I think in the case of the bug mentioned above, we have a case of neither attribute.

Well, they've certainly got "simply not correct" nailed.

a different "view" would be the 80/20 rule: it takes 80% effort to make the last 20% right.

I'm constantly surprised that people confuse code quality and value.

Without doubt, this is the most important lesson I've learned in my professional career.

Also, they may be "the best" (because they have a PhD, or something), but have no idea of what makes the best code

Yes, the code may suck, but the business is growing. What about those companies that prioritise code quality instead of growth? You probably never heard of them

> What about those companies that prioritise code quality instead of growth? You probably never heard of them

Please stop spreading that nonsense. Speaking from inside knowledge, some of them have strong, sustainable business growth and very successful recent IPOs. Some companies survive despite crap code. This does not make it the only way to work, or even the best way.

It would be nice if they at least focused on quality when it comes to security. I lost count of how many fast-growing companies shared their database with the world.

Yes, especially in the core areas (security/payments/etc) this needs to be handled carefully.

But don't overdo it beyond what is needed. Yes, the DB server needs a firewall, needs good access controls, needs backups.

But you probably don't need 5 slave DBs in 3 different geographical zones so that you "try" to achieve 5 9's of reliability for your service that has 100 sales per day.

> Yes, the DB server needs a firewall

Does it?

My recently-built DB machine has 4 listening network sockets that are bound to non-local interfaces: tcp/22:sshd (so I get in), tcp/5432:postgresql (because it's DB server, huh), udp/123:ntpd (so clocks are in sync) and tcp/443:nginx (serves some static pages with performance data).

I don't see any place where firewalling's needed.

Does the server need to be accessible to the world, or only to your web or other application server?

Many DB developers consider it good practice to be paranoid about who has access to the DB port, even if they can't authenticate:

http://www.postgresql.org/support/security/faq/2013-04-04/

"Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable.

"This is a good general rule for database security: do not allow port access to the database server from untrusted networks unless it is absolutely necessary. This is as true, or more true, of other database systems as it is of PostgreSQL."

Like in cars, firewalls are a safety measure; they provide a sense of security.

What if done program you don't realization is installed opens a port somewhere?

So not strictly necessary for correct operation, but then again security is all about being defensive....

"I don't see any place where firewalling's needed."

I don't see where I made any mention of your specific setup in my statement.

Famous last words. You won't need a firewall until you need one, but then it's too late.

Tight schedules are usually the reason behind these mistakes...

And it's only worth a billion bucks?!

Tumblr has weird bugs that seem to involve character escaping. Searching for tags that have slashes in them seem to end up parsed as URL segments and will return 404s, for instance.