Developers, in general, are very optimistic about the code they write. This is likely one cause of their estimates of the time required being low, as well as the various bugs that slip through because of corner cases that appear for the problem being solved. Often developers think they've considered the various ways this code ought to work and covered all the possibilities. Usually we find they've not thought about the problem from other perspectives and need to adjust their code.

They often also feel that their code is superior to others, and that they can examine a problem in a new way. One of the reasons that I think many developers want to rewrite systems in some new technology or new way, embracing the Not-Invented-Here way of looking at other people's code. They want to write their own solution.

Of course, many developers these days don't eschew all code from others. Usually, it's just other people in their organization, as a developer will embrace some random open source project they've discovered, sure that using this library/language/whatever will make their code better. While I do think there are examples of some new tech that is better than what's around, I don't know that any of them are a panacea. While F# is praised in many circles as better than C#, it's not widely used, at least according to surveys of the top programming languages in use (IEEE, SO). It must not be better enough to get more projects to use it.

What is widely used is SQL. In fact, if we look t0 other database languages, nothing else is close. While I'm sure plenty of those C# and Java programmers use LINQ or some ORM to produce the SQL code, I don't know many competent or highly regarded developers that can't write some SQL code or don't regularly write SQL.

There are some interesting ruminations on the optimism of developers in this piece. It made me smile, and I like the practical ending. While you can debate and discuss things, ultimately we need to ship code. And we are almost always better off using a technology we know rather than searching for a perfect new one to solve our problems.

When working with databases, relational or even most of the popular NoSQL ones, this means knowing SQL. And when trying to solve our database problems, in many cases, this means learning to better write SQL and build relational entities, not abandoning our platform for some new shiny one that we think will make everything run smoother.