Friday, May 20, 2005

Java vs. C# Series: Productivity 2

C# developers have a dirty little secret. We all have a list of annoyances, bugs, and workarounds that we deal with every day while we write C# code. These are the Anti-Productivity features of C# .NET.

I was first clued into this at the beginning of my .NET tenure when all the controls disappeared from a form I'd been working on for days. We had just hired an experienced C# programmer to mentor the Java guys as we got up to speed with .NET. When I brought him over to my desk and showed him what had happened he said, "ohh, yeah, sometimes controls do that with WinForms in Visual Studio..." This was the beginning of a long personal list of problems and subsequent workarounds that I've now collected over the past year.

See for yourself. Go to Google or Google Groups and search for "A failure occurred while attempting to start the compilation." This little goodie happens randomly as you compile your project throughout the day; meaning, you'll be working happily for the first few hours of the day then you go into compiler hell for the next two hours. The kicker is that it seems to happen AFTER the compilation is complete. And the problem is obvious by its description, isn't it?!

Or how about this ugly little compiler error: "
The process cannot access the file because it is being used by another process." Which file? Who knows!? Which process? Who knows!? Microsoft knows about this one and it looks like it will be fixed with VS 2005. That's no consolation to developers using VS 2003 every day. All that's painfully clear is the stress you might have been feeling before from a project deadline has now been magnified 100 times because you can't get a BUILD for CRYING OUT LOUD!

Also, as you're perusing the problems people are reporting on the web, notice that there aren't many answers out there. Dr. Spock! This... doesn't appear... to be... open source. And does Microsoft really have the gall to charge for a patch that fixes something that Visual Studio should just DO anyway?

The reason these annoyances frustrate me so much is because I can't remember dealing with bugs like these while programming in Java. And although I probably have, the point is, its such an extraordinary circumstance that I don't remember. I can remember using JBuilder and NetBeans years ago and being frustrated with their performance; but at least they worked properly. I do run Eclipse now. I can say that my experience with Eclipse' performance is much worse than my experience running Visual Studio. Then again, I work with code on a remote location when I'm running Eclipse. And frankly, Eclipse does exactly what I need it to every single time I run it. In any case, I think there's a subtle but significant difference between performance issues and things that just plain break. It was fascinating to me how our experienced C# guy was just resigned to the fact that this was normal. I guess I'm there too to some extent...

So to join this back in with my Productivity thread, I just want to make it clear that I truly have been more productive using C# .NET... but I could be so much more productive if I didn't have to deal with all of these inexplicable issues.

1 comment:

darprice said...

Hi Joe. I'm kind of surprised by your productivity comments between Java and C#. I'd definitely like to have some more defined clarification as myself and others tend to take the same things you are talking about and develop in java at a very rapid pace. There is probably some productivity we lose, but we consider it minimal to the fact that our code will run pretty much anywhere without fundamental changes - hence no need to recode if there is a shift in server technology - which we've seen quite a bit happen over time. Also, just wanted to let you know that I moved Java Brew from javabrew.blogspot.com to consulting-bdi.com/javabrew. Looking forward to more comparisons between the two as I have a very limited knowledge of C# and am not opposed to learning more.