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.

Where does that leave InnoDB? It's the only game in town for a tried-and-true constraint-enabled MySQL database. I was to understand that Oracle bought that engine up years ago. Were that single piece to go missing, MySQL would be set back to the stone age. The lack of mention about that engine, and lots of talk about third party engines concerns me.

Yes, you are a professional. But you aren't acting like one. Defend the profession by practicing the disciplines you learned in school and afterward. That means:

  * using revision control
  * writing tests or behavior specs before writing implementation code- no matter how trivial
  * aggressively refactoring and keeping your code DRY
  * writing software that communicates its intent so well that any developer can maintain it; not just simply to the point that it "works"
  * using an economy of technology and infrastructure appropriate for the problem at hand

It means having the integrity to stand up as a group and declare that it would be unprofessional for your team to write software without tests, or without a clear schedule and set of reasonable expectations. Professionals do that. As an example, a doctor wouldn't perform a surgery without "scrubbing in" first- no matter how dire the situation before them. The discipline makes their profession possible.