The Compulsive Coder

So let’s say my LAMP web application needs some set of functionality. There’s a class or set of classes out there that provide…usually about 80% of the functionality that I need. Of course, because most PHP code libraries don’t have a .NET-slick API, I usually end up parsing the code down to the base class to get my arms around the thing.

About halfway through this venture, I inevitably find myself thinking: “Screw this, I’ll just hand-roll this puppy myself.”

Nine times out of ten, that’s what I end up doing. I rationalize this using the following reasoning:

1. I’ll know the code because I wrote it, so if I need to tweak the library it’ll be quick.
2. Most webbish APIs suck. Especially open-source APIs. I’m good at writing webbish APIs.
3. By the time I get this library wired up so it works how I want, I could have written the thing myself.
4. Rolling my own makes me a better programmer because it forces me to deal with a challenge that I might otherwise sidestep by using a 3rd party library.
5. I’m smarter than everybody else, so NATURALLY whatever I write is doing to be better (note mild sarcasm).

Problem is, lately I question this reasoning. My brain generates the following counterpoints:

1. Yeah, you’ll know the code, but that means you have to take the time to develop, debug, and test it.
2. You just think they suck because you can’t get them figured out inside of five seconds. Not so smart now, are ya?
3. You’re fooling yourself, it’s going to take you longer to write it and it’s going to be so narrowly focused you won’t use it again.
4. Yeah, or it makes you a worse programmer because you’re not exposing yourself to other people’s styles of coding, which may be more ’standardish compliant’ than yours.
5. Keep telling yourself that. Is that why you keep round-filing your old libraries because you look at them and think they’re crap and need to be rewritten?

Yeah yeah, I tell myself, but here’s the ultimate issue: I’m a web application developer. I’m not writing non-managed Win32 apps in C++. Web apps just really aren’t all that complex. My resistance to Other People’s Code isn’t the same as my saying, “The Win32 API sucks, I’m going to make my own.” Ugh. That would be an exercise in self-flagellation.

Of course, there is the argument that I’m reinventing the wheel. Yeah, well, what if the current wheel sucks? I’ll make a better one.

And so it goes.

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.