The Compulsive Coder

I would.

Let me explain…

After diving into the .NET world head-first over the last 4 months with C# in a pure .NET shop I must say my reticence towards embracing the core technology has faded somewhat. Well, ok, a lot. It *is* very productive. And the C# grammar has some very handy features I will allow.

But I still feel a bit dirty not cleaning up after myself (I detest GC at a fundamental level, it perverts a language enforced ctor/dtor element to the acquire/release model intrinsic to OO programming, but that’s a different post….) … but, alas, I love the .NET framework. It’s what MFC never was (or Ritchie forbid, ATL) - or any other monolithic framework designed to help with all the grungy bits of code we all know and hated in a pure Win32 world.

Anyone who has coded perfmon counters, version info blocks and anything network related along with a ton of cobbled together bizarre interfaces (raw com anyone?) that comprises the life of a low level win32 jock must agree immediately, or risk being discarded as disingenuous.

So I’ve brought this up to coworkers - fellow C# jockeys mind you - would you write pure (unsafe, *gasp*) C++ if you had a library as clean and elegant as the .NET framework?

I sure would.
…If for no other reason than sheer romanticism.

I love .NET. I mean, I really think it’s incredibly cool. The speed with which an application can be constructed without having to get all low level is simply fantastic. In the hands of a developer with a solid grounding in the fine art of creating elegant and portable software, the power of .NET is…seductive.

I hate .NET. I mean, I effing loath it with a fiery passion. The drag and drop wizardry of the studio and the lack of knowledge that is required to be able to get an application running has so significantly lowered the barriers of entry that the workforce is becoming populated with “programmers” whose only experience is with Visual Basic using the .NET framework with a version of the (unbelievably excellent) Microsoft Visual Studio. I can’t bring myself to refer to these individuals as programmers, because they’re not.

They’re VBtards.

I (well, we, HumanAbacus and I) made an egregious error in judgement and hired one of these VBtards, and I experience at least an hours worth of self-loathing a day for making this decision when I knew better.

I had my first code review with the VBtard a few days ago. To say that after fifteen minutes I wanted a stiff drink would be a mild exaggeration. I wanted a Tanq and tonic, hold the tonic.

Problem One is that the VBtard doesn’t understand why cutting and pasting code that he found by Googling could be an issue.

Problem Two is that the VBtard doesn’t understand why he should take the time to parse through said code so that he understands what said code actually does.

Problem Three is that the VBtard doesn’t get why encapsulating an operation or set of operations into a function inside of a class or set of classes is necessary. The VBtard thinks it’s acceptable to cut and paste the same snippet of code and just change the object or variable in question.

Problem Four is that the VBtard doesn’t think about using abstraction to handle two the integration of two different 3rd party APIs that perform essential tasks with identical input parameters. The VBtard doesn’t even have any idea what abstraction means.

Problem Five, the most significant problem all, is that the VBtard does not understand why these problems are, in fact, problems, even after HumanAbacus and I both attempted to explain the issues.

I know I’ve already covered this, but I’m absolutely mortified at how just how poor my (our) hiring decision has proven itself to be. How did I miss this?

Ok, enough self loathing. For now.

So what, you’re asking, does this have to do with .NET? After all, it’s not the fault of the language, the .NET framework, or the IDE that little Johnny can’t code.

No, it’s not, but .NET performs the classic role of an enabler. It enables VBtards to delude themselves into believing they’re programmers by enabling them to create applications without having knowledge and understanding of the fundamentals of object oriented programming and the art of programming in general as a prerequisite.

Here it is in a nutshell:
.NET in the hands of a programmer is an incredibly well thought, powerful tool.

.NET in the hands of a guy with the 2005 version of the Studio and a background in VB is nothing but trouble.

I respect the fact that MS took great pains to make the GC in the CLR high(er) performance than most (slow) GC implementations in the past. Mid Life Crisis and Always Penalized Finalizers aside, they did a good job on the implementation.

But there’s a vast difference between doing the right thing and doing the thing right, I’ve grown to understand. The reason for GC to begin with, in my estimation, was to improve software quality. Many, many applications suffered from memory leaks brought on by lazy programming practices - I don’t question that, there’s no controversy.

But what about - instead of going the GC route - we improve the tools and education? BoundsChecker is a staple run for most serious hard core developers I know. And guess what? Most of those guys find little if no issue in their software. Why? Good practices, attention to detail.

But now, here we are, reaping what we’ve sown. Again, there are MANY good things in the .NET paradigm, but alas, this is a GC rant, so I shall continue and pose this question: Has GC completely solved the core issue of memory management?

Yes and no.

Check these out, straight from the horses mouth:

Rediscover the Lost Art of Memory Optimization in Your Managed Code
CLR Inside and Out:Investigating Memory Issues
Inspect and Optimize Your Program’s Memory Usage with the .NET Profiler API

I would submit to you, that indeed, after all this time, it’s true: There Is No Silver Bullet

We’ve simply moved issues around the Issue Space that is software development. I would even go so far as to offer up a axiom based on Brooks’ seminal work:

Issues are neither created nor destroyed, but rather, change from one form to another

Yup, that’s right. So now our memory issues are much more subtle - and have profound and often unexpected impact on application performance. But the average developer is probably shocked by some of the content in the above articles since they have “put their faith” in GC and think that memory issues are a thing of the past. Which is, well, simply wrong.

And the affect of GC language grammars? Well, as substantial as the above issues are (not the problems themselves, but how they morphed into a more subtle animal which hunts on the trusting yet unsuspected dev slumbering in his tent pitched on Mount Redmond) this might be my biggest complaint.

One of the core Pillars of OOP is the acquire/release resource approach which is elegantly modeled via constructors and destructors (pick your OOP language). With the advent of the CLR and it’s GC approach please say goodbye to deterministic destructors.

And this is progress somehow? Or a vain pursuit of the Silver Bullet?

The result has been a serious dumbing down of the average developer - shoot, GC has rewarded lazy programming - simply because paying attention to memory is just “too hard”?

And for all the progress (yes, I fully admit there has been progress in this area), the issues have for the most part simply morphed into newer and more subtle forms.

First off, let me frame this post by asserting that I’m not a Microsoft hater - far from it, actually. I dig many of the dev tools (i.e. Viz Studio), the tablet pc os and their mobile technologies are pretty cool.

Additionally, the .NET family of technologies certainly has some really cool stuff buried in there. Beyond the CLR and some of the (potentially cool uses) other low level technologies, the overwhelming coolness to .NET is the well packaged framework. Building on the lessons learned from older frameworks and APIs (mfc, atl, win32, swing, jfc, yada) the Mother of All Frameworks arose. And we - the dev community collectively - clapped.

Who has written a low level C# service and not oohed and ahhhed over how simple it is to do such tasks as, oh, add performance counters (which are horribly nasty in raw win32), implement a windows service or access networking resources? I don’t care how low-level you consider yourself, you probably look on with a sense of awe with how slick the framework itself really is. Well done, ms, well done.

Ok, enough cheerleading … on to the rant aspect of this post…

There’s a certain allure to a shrink wrapped prepackaged dollop of code that I can’t deny exists. I mean, given a particular task, how cool is it to find a class or assembly or com object already written to solve said task? Sweet, I can go play some video game tonight and not be stuck at the office. A bit of that ain’t a bad thing, right?

Well, here’s my issue. A lot of developers I’ve met these days are completely addicted to drag-and-drop Wizardry. They have Wizarditis. Their approach to writing something new and outside of their comfort zone is “Show me the wizard!”

What’s a symptom of wizarditis, you query? Well, here’s a few, and I trust you can extrapolate from there…

• Do you break out in a cold sweat if you can’t find a free .NET assembly for sending secure SMTP mail messages?
• Do you head to monster.com if you are tasked with writing a TFTP server and your google searches come up shooting blanks?
• Do you lockup whenever a customer issue is brought to you that appears to be - Gasp! - inside the blackbox of one of your shrink wrapped bits of code you googled off the net?

If this is you, you may very well be among the afflicted. Never to worry, it’s not a terminal condition - IF you act right away.

My prescription for you?

The next time you have to solve a problem you have no experience with, write your own set of classes from the ground up. Every. Last. Line.

That’s right, the ground up. Use as little prepackaged code as you can get away with (search/sorting you get a pass) to accomplish the task at hand. And mind Occam’s Razor, make it only as complex as needed, no more. Code for contingency cases. Think about run time traces to make it diagnosable for field issues. Think about reuse. Use good OOP practices. Research the thing at hand first. Is a standards based protocol you need to work with it? Read the original RFC. Learn, dig, be curious.

Now clearly I’m not saying do this for every last thing. You have customers, you have a boss, you have deadlines. But every so often just say No to the “Wizard” approach to software. Dig in, understand stuff, learn and grow a little.

We’ll all be better for it.