Doesn't it? The "ignorant majority", as you call them, simply do not give a flying flip if 13 people are still playing Halo 2. They don't care that you can't play Halo 2 on XBL. Frankly, I don't care either. Eventually every game you buy and love multiplayer will have no one left to play with. It sucks a little bit that Microsoft has the power to move that date up, but it doesn't suck enough for me to not buy XBL games. Don't expect the "ignorant majority" to fight a battle for you when they simply do not care.

Well that explains everything. The < operator, when typed straight from the keyboard, gets filtered out. The parent post, like me, didn't properly check his "preview". Try "i <= 10" ftw. Oh btw, Anonymous Coward = me, forgot to log in.

The problem, I think, runs a little deeper than all that though.

SQL is unfortunately tied fairly tightly to an RDBMS implementation. All those "join" statements, various ways of expressing "constraints" such as "foreign keys" - all are considered "integral" parts of SQL.

No, you don't have to provide them. A Post-Relational like Amazon SimpleDB could, theoretically, use SQL for querying and just trim back the feature-set.

But perhaps it'd be wiser to look at a query language more specific to the Post-Relational model?

Perhaps SQL stopped being "SQL" and started being "Structured Relational Query Language". *shrugs*

What is proper design?

Is it spending 3 weeks drawing diagrams that, in 3 more weeks, won't represent the true state of the system at all?

You draw your diagram. I'll spend 1 night doing a rough-shot prototype. I'll "hack" it.

Then I'll use that prototype when I create a well-architected system. Then, since I share my stuff lots, other "hackers" will help improve that design.

Be careful when you discard one set of "propaganda", and listen blindly to another. Maybe "hackers" aren't so "evil" after all. After all, I don't remember signing up for any cult.

Oh really? http://en.wikipedia.org/wiki/Hacker_ethic Hacker Ethic is knowledge sharing, decentralization, respect based on merit. Compare that to the "professional" environment where certain races or genders can't advance past the "glass ceiling". Yup, those hackers sure suck. Generalizing is fun.

Dude, RTFA.

Paragraph 1:

Cyberchondria is when you search the net for your symptoms and suddenly start panicking because you think you might have something bad.

This suggests the opposite of your post - you should consult medical professionals.

Dermatology is a completely different beast, because many skin conditions have no real tests. The creed of dermatology is "if the area is moist, make it dry, and if it's dry, make it moist". I've had a problem for 2 years now undiagnosed. *shrugs*

Man, you've taken the article out of context. You're implying that what you're describing relates to the Lifebook4Life program - it does not.

For anyone too lazy to read, here's what they -actually- said.

From TFA:

They're offering full refund on the -first- sign of trouble. It's only fair that they exclude normal wear and tear. No company can make money by giving you back all your money every 3 years because you cracked the case, come on!

Sorry Duckie, but you're still missing the point.

I'm working on a project that's been going probably 10+ years. No, I wasn't one of the originals - none of them are even around. So just pretend for a moment that all the technology we have today was available 10 years ago. You're pretty pro, think you can get _all_ of the requirements for the next 10 years and beyond out of your client on the first try before you write a single line of code? Good luck.

Customers don't know what they want. Period. You can ask them, interview them, and you'll get a lot of very telling answers. You'll build what they said they wanted... and it's not what they wanted! Why not? Because it was what they wanted 6 months ago when you started.

Worse than that, customers have a nasty habit of not knowing what they want until its delivered. We did a photoshop mockup of a UI for a feature we were adding, and got it approved by our customer, before proceeding on a recent feature-addition. He still liked it the day we tried to deliver... until he used it. Then we spent another two weeks changing the UI and some of the underlying functionality linked to it.

The fact of the matter is that the requirements and scope change. You can't prevent it. Yes, you should spend some time determining requirements, try to minimize the harmful effects of change, but you cannot _cannot_ prevent it.

Perhaps he might even hire an Agile programmer instead of a Waterfall one. Who knows.