I've been a developer for over 30 years. No, it is not
The problem is the size of the problem domain and the sheer complexity of it. Take the ISO date example. Who has time to be an expert on every single aspect of ISO dates? Being blissfully ignorant on that subject
my first question as a developer is "why doesn't the ISO date system operate as expected?" Is there a bug in it? If so, why? What's the problem and why would it bite on Jan 1st to 7th of 2013? And, being this is ISO approved, why would there be a bug at all???? If you can't trust the ISO who can you trust?
Take my current developement project. I'm implementing what could best be described as a "whole business automation system", using VB.NET for the front end and T-SQL for the backend.
That's two entire, and very complex, languages I have to know. Further, I've only known these languages for about a year now, while keeping up with all the other jobs I have to do as our company's one man IT shop.
The point being I already know I'm not
fluent in either VB.NET or T-SQL and probably won't be for about 3 more years. By "fluent" I mean "know the languages inside out and backwards, able to wring every bit of performance and know all the gotchas to avoid".
In the meantime I've got to create a program with a predecesser that consisted of 100,000 lines of code, written in a system I've been fluent in for 10 years.
Oh, and did I mention my users won't take the time to beta test the new system? Because they don't have "time to play". Oh, and that my tool budget is severely constrained?
And let's not even talk about all the (very complex) tools involved in production, from the ERD tool, to all the Red Gate tools, SSMS, Visual Studio (and add-ons), the profiler, the unit test system...
Easy my Aunt Sally! :-P
So what do you do in that situation? You keep it simple. You avoid all the nifty tricks that would probably be faster or need less code, but have unforseen "gotchas" and inexplicable interactions with other features. Since you can't
know everything, you concentrate on a small subset you know won't break.
Then you refactor as you can over the lifetime of the system. (The last system lasted 13 years!)
And that, my childen, is how Equestria was made! (laughing)