[vanessa]

I think the author probably meant this on a broad, business and marketing strategy level, but the concept holds for programming and database design as well. Until you have worked with highly scaled or long-lived programs, you probably shouldn't make calls on what kind of "hacks" are okay and what aren't. It's the knowledge of the rules and the experience of learning why they're the rules that really enables you to break them with little cost and sometimes huge advantage to your organization. I think this is true of NoSQL solutions in some shops - until you understand the purpose of normalization and the ways it affects data integrity, maintainability, performance, etc you really shouldn't be allowed to "break the rules" by denormalizing, using only unstructured document storage, etc. They certainly have a place and can be great tools, but all of their weaknesses and problems manifest when implemented blindly/without regard for "the rules" and where they came from.