"There's a BUG in ...." vs User Stupidity and Blanket Statements about .NET

I"ve been doing this .NET thing since they gave out the first BETA at PDC in Orlando 2000. That's nearly FIVE years of toil and learning with the .NET platform. And I mean toil, because early on I had the good sense to completely give up on Visual Basic and go almost 100% with C#. Boy! That was a GOOD decision.

And one thing I've learned well, especially from my own mistakes and all the newsgroup and forum posts I've read and answered:

If you think you found a "BUG" in .NET, think again, because 99% of the time it's just USER STUPIDITY (and sometimes even arrogance!) that is the real problem.

There are plenty of things you can do wrong that will make it "look like" .NET is fubar, and almost without exception, it was YOU, the developer. That's not to say there aren't any bugs - of course there are. But most developers never even run into them.

It's very easy, for example, to write a stored procedure that attempts to access a table by the wrong name. This will compile just fine. At runtime, you are going to get errors that "look like" there's something wrong with the SQLDataAdapter's Update method. Nope! .NET is simply reporting the news of your stupidity, and unless you learn how to read the road signs it gives you, it may take you a long time to fix it, since you are already off "reporting a bug" -- instead of writing quality code!

Unit tests are extremely helpful in preventing errors and insuring the integrity of your codebase as projects evolve and become more complex.

But I wonder what percentage of .NET developers know how to use NUnit? Or who have read a book on unit testing or refactoring? I bet, less than 5 percent.

Think about it.

Blanket Statements About .NET

Another thing developers should be vigilant about is the temptation to accept "blanket statements" about some issue from Self-Proclaimed Guru-Types, many of whom are simply parroting something they've heard or read from some other SPGT online. A case in point is the blanket statement (which was recently made on a public newsgroup) "You should always use StringBuilder for string concatenation because ... blah, blah"

Wrong! Fact is, StringBuilder is NOT always faster or more efficient for string concatenation. I've seen several tests with charts showing that somewhere between 5 and 7 concatenations, StringBuilder is LESS EFFICIENT than "+=". Here is a link to one..

Furthermore, Jon Conwell did an excellent blog piece that shows from his tests that the String.Concat function outperforms the StringBuilder by 2.3 times! Sure there are provisos such as pre-initialization and other considerations. However, the point is, don't accept everything you read as "The Gospel". Test, and verify.

I leave you with this little gem from Tesla. When you plug your PC into the AC outlet in the wall, please thank this guy, as he invented it:

"The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane." -- Nikola Tesla