More responsible, I would say. You expect a junior to make mistakes; the company should be structured to handle that happening.

Though I would look askance at whoever hired a philosophy grad as well, to be perfectly honest. The author admits he didn't have the experience to spot bad practice at the time.

Actually even senior developers or architects make mistakes. Philosophy grad or not, it doesn't matter. That's to be expected.

What's more questionable is:

* Developers have access to the production database from their machine, while it should only be accessible to the front machines within the datacenter.

* Junior developers don't need an access to production machine, only sysops and maybe the technical PM.

* No backup of the production database. WTF???

If they had a hardware failure they would have been in the same shit.

I'll add another one:

* No Foreign Keys

Attempting to clear the table should have just thrown a constraint violation error.

Well, depending how you configure your cascade clearing the user table could have cleared all the other tables also :)

"on delete cascade"!

True on MySql with InnoDB, wouldn't be true with postgres.

You'd have to use TRUNCATE CASCADE on postgres to avoid the foreign key error.

Exactly!!!!

It's a nice theory, but not everybody has that much staff. You can get by with proper backups and running against local copies of production.

Constrains also act like bug protections. If you screw up your database tells you right away, and not a beta tester much later.

You're preaching to the choir. :)

You don't expect a junior to make mistakes, you expect everyone AND everything to make mistakes/fail. Backups and separated environments is the least you could expect from a company earning millions.

Well - to be fair - if the company's practices include developing on the production database and not doing daily/weekly backups, then hiring an inexperienced Philosophy major is the least of their problems.

Also, someone who actually had the development experience and knowledge of better-practice would not have taken that position.

Literally every engineer who didn't think to have a dev database can also be responsible. This is just a case of 'shit happens' since nobody had the sense to not work on, not back up, the live db.

This. Times 1000. I would even go as far as to fire the CTO because if the data is your bread and butter, the you protect the data.

Protecting the data is called a disaster recovery (DR) plan in those big outdated companies that people like to make fun of.

The reason that these companies have a DR plan is to tell the CEO that 'when' (not 'if') all of the data goes away, (a) how long will it take to get it back and (b) how out-of-sync will this data be (2 minutes from freshness? 6 hours?).

Perhaps more responsible was the person who decided that development work happened on the production database.