Another fallacious idea I, and many others, had was to treat database instances like programs that need to be installed. Again, there are many things wrong with this line of reasoning, but something positive came from it.
You know me... "Mr. Positive."
This particular step in my journey to a class of databases bore what was, at least for me, a pretty subtle value. Part of the subtlety came from the fact that the installer paradigm looks like it works for longer than a lot of its predecessors, which tended to break down extremely early. Part of it was my own stubbornness - I was spending so much energy arguing the small improvement that I couldn't see the bigger improvements waiting just around the corner.
I'm pretty sure that's irony: that this way of thinking was so successful kept me from seeing other, more successful, ways of understanding a problem. Wait. Maybe that's not irony. Maybe that's the human condition. ...or maybe those things do not really oppose one another.
Anyway, grain of truth in this way of imagining database build technologies is that it recognizes the importance of discrete, tracked, testable deltas in design and highly controlled, repeatable ways of introducing those changes. That ends up being a pretty fundamental concept. It serves as the basis for building a testable class of databases, enabling test-driven database development, and ultimately unlocking database agility.
So there you have it. Another step in the journey. Another failure to hit the mark. Another lesson that built to what we know today.
