Let me pitch you this scenario. You run Facebook, and you have all the software and all the data. A catastrophe occurs and you lose everything, and due to a mistake in the way backups were made, you can choose to restore the software or the data, but not both. (Somehow, restoring the software will destroy the data, and restoring the data will destroy the software). Which one do you choose?

Although that makes for an interesting conversation, it is a red herring / strawman / false dichotomy with respect to this discussion.

> To us, what's most important is the data, so everything else must serve that end

To you, yes, and I don't fault you for defending that perspective. But the real master who must be served is maximizing "profitability" while maintaining an acceptable level of risk.

Anyone from either side of this argument who ignores the very real advantages from the other side, or the risks from their own side, are the only ones who are totally wrong. (Which would make the author of the original article the one that is most "wrong" in this discussion, as far as I'm concerned.)

I don't disagree with you. The point of the hypothetical situation is to dislodge a naive programmer from the sense that the code is the most important artifact and the database is just storage, a servant. I agree with you and jshen, that reality is nuanced and turns on the business, the system as a whole.

"To us, what's most important is the data, so everything else must serve that end"

This is ideological, right? What's most important is the business. Anyone that starts from the assumption that everything, EVERYTHING, must serve the end of the data, is wrong. Right?

We can make up interesting dilemas all day. How about this one. There is an optimization that facebook can make which is shown to increase monetization by 10%, but it creates soem risk of data corruption. Engineers estimate that it will corrupt 0.01% of facebook posts. Do you choose a 10% increase in monetization, or does everything have to serve the end of data integrity?

Yes, it is ideological. But you're right, at the end of the day, it's the business that matters. Developers are going to have guiding principles and it's not a bad idea to evaluate them every now and then; I hope my hypothetical at least illustrates why the alternative opinion exists. I quite like your hypothetical situation, it's the best retort, and offers a great motivating example for the rise of NoSQL, where ACID compliance simply doesn't make as much business sense as scalability with less validity.

"I don't believe in hypothetical situations" -- Kenneth the Page, 30 Rock.

Hm, that's a great question, even outside the scope of this ORM context.

I would probably pick the data. It's what can be monetized and it's impossible to regenerate.

Having to recreate the software might even be beneficial in the long term if your engineers are careful enough to avoid second system syndrome.