VB .NET Is Too Darn Hard

A reader agrees with Rockford Lhotka's assertion that software is too darn hard to use, and recommends that Microsoft think about this from the perspective of Visual Basic .NET.

• 08/01/2006

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

VB .NET Is Too Darn Hard
I agree completely with Rockford Lhotka's conclusions in his Guest Opinion, "Software Is Too Darn Hard" [VSM April 2006].

It seems obvious, if commonly ignored in large companies, that the development process has become more important to Microsoft than the product a language can produce. I think it's equally obvious that Microsoft condones and promotes this situation by releasing increasingly complex tools that have brilliant technical innovations, even if the majority of developers aren't yet capable of using them.

VB.NET itself is an example of developers getting carried away with something they think is cool and exciting to use, but is of more dubious value to its intended client. That might sound like sour grapes, but let's look at this argument in more detail.

Visual Basic 6 was often touted as the world's most used programming language, with estimates ranging as high as three million developers. Of course, these programmers were often from backgrounds other than computer science or IT. VB6 programmers were frequently accountants, support providers, and others who knew intimately the business issues that they found themselves working on. But it's also the case that many of these same nonprogrammers were imbued with an interest and some ability pertaining to the technical side of the equation.

Solutions they turned out might not have been as robust by IT standards as you'd see from traditional programmers, however in many cases, their intimate knowledge of the business requirements led them to being able to provide solutions that dovetailed exactly with the needs of their respective departments. This speaks to the extraordinary empowerment VB provided to those with limited programming experience, but some degree of technical savvy.

Nevertheless, the VB code created by these developers was often lacking the elegance you'd prefer to see in a business application. Odd as it sounds, this fact presented an opportunity for professional programmers to rewrite these applications, improving them both from a UI perspective, as well as restructuring them so they were more maintainable for others who had to update the applications down the road. The result was tons of software written by millions of programmers that triggered a boom in the software industry and growth beyond any imaginable business expectation. It was also an enormous boon to Windows; Visual Basic provided businesses with a terrific incentive to use Windows.

Microsoft's release of VB.NET turned this situation around in a single release. VB.NET is a highly technical language that requires much more formal technical education to use properly, even when creating relatively simple applications. In my opinion, it is much more like C++ and its cousin than what developers had before the release of .NET; it effectively culled the herd of programmers of sometime programmers and hobbyists.

No doubt, some people who shunned VB because of its nonprofessional reputation were pleased by this development. But something significant was lost in this transition, something that later versions of post-VB .NET haven't restored, even with several new productivity-centered features. It's ironic that giving VB developers the power they'd always pushed for also made the language feel so different from the language these developers initially got to know and love.

All this brings me back to Rockford's points in his article. Visual Basic .NET does include more advanced capabilities, but it does nothing to shorten the time it takes to develop applications relative to the amount of time it took to create these apps in VB6. Consider the problem from the perspective of cost-per-feature. Where I work, the increased cost-per-feature with .NET has upper management contemplating using outsourcing for the first time instead of using available talent to create usable applications to run their businesses.

I'd like to see Microsoft absorb and apply the lessons that Rockford Lhotka addresses, not just in VB.NET, but across its development environment.