The Visual Basic Culture

I started developing software over 10 years ago, and when I did I started with Visual Basic 5. I was fortunate enough to work from a book that encouraged and often required object oriented principals. While not a true OOP language, we did the best we could with the limited capabilities of VB5 and then VB6. Fast forward 4 years my first experience with .NET. I was now developing with a tool that allowed me to fully explore the advanced programming techniques and practices that I could only emulate before. I've spent a lot of time reading different books on Object Oriented programming, development patterns and best practices. I finally had the means to structure, engineer and design code that could be easily implemented and maintained. However, herein lies my dilemma. I naturally went with VB .NET as opposed to C#. I read many articles on the differences, and it seemed that there wasn't much of a difference other than syntax. True, I know there are some pretty significant differences now, especially in the earlier versions, but at the time (and at my experience level), the differences were negligible. Now, 6 years later I'm writing this post to my blog to discuss the problems I have found with Visual Basic .NET. I should rephrase that last sentence. It's not the language that I find lacking, but the developers (in my experience) that are developing in Visual Basic .NET.
I would estimate that 1 in 7 VB .NET developers are what I would consider 'good' developers. On the other hand, I would estimate that 4 in 7 C# developers are 'good' developers. These numbers are just estimates on my part, and based on my experience, but I bet I'm close. My theory is that most VB .NET developers are from VB6 backgrounds and are simply doing what they have always done, only in a different language. Now you’re asking, “What is it that they have been doing?” I'll answer that by saying, 'Writing a lot of code'. These developers, again this in my experience, start all projects by writing code. Not a lot of forethought or design. Maybe a rough idea of what they want is jotted down in a notebook or on a white board, but from there they simply start typing away at their computer and writing code. They come up with a prototype that functions and then they simply keep adding code until the prototype becomes the production version and they add more code to handle any and all changes to get the functionality they need. I can tell you that all but very few of the VB developers I've worked with in the last 10 years wouldn't hesitate to create a method in the UI that would contain over 100 lines of code. This is at the time of creation. Three years later and the method is bloated to 1000 lines of code. In my last job, there was a web method that simply allowed clients to submit orders. This method contained close to 1200 lines of code. The best part of this is that this web method was also called from the UI of a web application because it simply contained so much business logic that it was almost necessary, albeit insane. This is often the logic of the VB developer. This is how you encapsulate code and logic, create a single method that contains all the logic and call that method from everywhere. The best part of this real life example is that the web page I referred to above contained just under 6 thousand lines of HTML and over 7 thousand lines of code in the code behind. But that's not all, the page also contained a user control that also contained a few thousand lines of HTML and another couple thousand lines of code. Now this is an extreme example, but I should point out only myself and one other developer working on this application thought there was something wrong with this type of development. This was the norm and not an exception.

What I've found in my experience is that the majority of VB .NET developers don't care about writing robust maintainable solutions. They simply want to write code that works today, and give no consideration at all to future enhancements or scalability. This kind of development might work well for creating very small applications that are not meant to be modified or enhanced. However, I haven't come across many of these types of applications. What I have come across is this kind of mentality being applied to full scale, very large applications. And the result is always the same. My last employer had a very simple application that did nothing but allow users to submit orders. They had a team of 5 developers, 2 DBAs and upwards of about 6 managers who were committed full time to doing nothing but maintaining this application. The application was constantly breaking down and failing at multiple points. No one there was quite sure how the whole thing was tied together. The IT Directory (author of the original application) was famous for quoting, "Well it all worked when I was the only one working on it."! Ha, here we have the VB developer’s mentality in a nut shell. How wonderful it would be if every developer could simply work on his or her own code and never expect anyone else to have to maintain it. This guy thought he had written great code, because 2 years ago it all worked. What the VB culture had taught him, and he in turn passed on to other junior developers, is that this is the norm. He created many, many state maintaining objects he referred to as business objects (a term he must have read about once somewhere). These were all mapped to database tables. Each 'business object' contained a property to match each field in a table, and then did nothing but persist data to the database or retrieve that data from. There wasn't an ounce of business logic in his 'business' objects. All the business code was contained in the user interface code behinds, although there was the occasional exception of an web service method with a few hundred lines of code.

My point in all this is that while I have yet to be shown that C# is a better language than VB .Net, I have first hand experienced an extreme difference in the developers of each language. I’m convinced that it isn’t the language, but the culture of the language that makes the C# developer so much better than a VB .NET developer. I’m also convinced that if you were to get rid of the VB .Net language and force all those VB .NET developers to start writing C#, you will simply have more bad C# developers.