// WHY
int WHAT(...) {
      return HOW();
}

A couple of generations ago, you needed a bonfire in the middle of the street to get rid of books full of unpopular ideas.
Today, that can be accomplished very quietly with a few inode updates.
The Internet and DRMed information is like Alexandria written on gunpowder-impregnated flash paper.
Information is easily linked and too rarely duplicated. Unplug a server, and it goes away.
We can stand around and shrug when some paedo gets his dirty book pulled from his tablet.
Nobody will be there - or care - when it's our turn.
Mark my words.

Hmm. In my many years of experience in software development, I've yet to find anything that _specifies_ software behavior as completely as the software itself. Moreover, "repeatability" isn't important at all in software development. It's critical, of course, on an assembly line. So the very goal of ISO/CMM is fundamentally flawed.

That said, documentation of the expectations and capability of software is paramount. So you write your behavior specs first. Then you write code that meets the specs. Oh, and those specs can't be in a dry, dead, out-of-date .docx file. Or in some contrived, expensive tool. It needs to be _in the code_ PART OF THE CODE- an automated test suite that can be run instantly and report immediately the second anything is out-of-spec.

In this way, both the software and the specifications it is intended to meet grow and change together. So you don't have to have business people and business analysts having to make all the hard decisions up front in a vacuum. You get to show them work frequently and be able to respond to changes as their needs evolve.

Development is faster. Progress is measurable in terms of business requirements met. Maintenance is far more inexpensive. Best of all, there are working examples of every bit of code- the tests are current, living, breathing documentation of how each method and unit was designed to work and what business value it was explicitly intended to support.

That's what you need to write your code. Forget the over-priced tools. Anything less is cheating your company or client.

You are remiss in not mentioning github.com which does the favor of free, immediate online hosting of OSS projects and content under git. I don't know how many presenters I've seen with their slides and demo code all on github. It's the killer app that makes git really rock.

SQL syntax is dated and very obtuse. Just look at the different syntax between insert and an update. ...wouldn't you rather just have "save"?

Object-relational mapping is cumbersome and mis-matched in SQL. 1:many either yields n+1 queries or a monster cartesian product set. And, what about inheritance? It just doesn't jive.

It isn't about losing ACID- although not every purpose needs ACID. Your average shared drive filesystem isn't ACID, for example.

When you have anemic domains that aren't nailed down and need to be readily flexible without big re-designs, JSON-based No-SQL works very well.
When you want to avoid n+1 and have well-defined data needs with 4MB of data across your object graph, No-SQL works... very very well.
When you want to segregate the business services and its backing data store from the separate concern of BI, No-SQL keeps the riff-raff out of your data store.

It's different. It solves different problems. Keep your mind open.