Paul Vick is the big kahuna when it comes to VB.NET. When he joined Microsoft “in its antediluvian past, namely 1992,” Windows 3.1 was the hot new operating system taking the world by storm, a little project named Visual Basic had just shipped, and he started out on an unreleased database product named Microsoft Access. Fast-forward a few years. Vick moved over to work on the Visual Basic compiler proper just as the team started moving it to some new runtime that Microsoft had decided to build called ".NET." Four years later, they shipped Visual Basic .NET 2002. Says Vick, “Along the way, I moved from being a developer working on code generation to managing the compiler team and working on the design team for the language to becoming a technical lead on the product. Now I'm working full-time on design issues, as well as writing the Visual Basic language specification, a Visual Basic language reference book, and a weblog.” In this interview, find out what Vick thinks about programming methodologies, why developers haven't converted wholesale to VB.NET yet, and what's wrong with programming languages' database interaction.

DevSource: How'd you wind up with .NET in the first place, much less as a rock star? What shaped your attitudes on software development?

You can't call me a rock star until I can get a bowl of green M&Ms in my suite. Or until I can get groupies, whichever comes first. (If it's the groupies, please don't tell my wife, OK?)

As to how I got into .NET, dumb luck and being in the right place at the right time definitely played a part. I originally joined VB because I'd decided I wanted a change, I had enjoyed my compiler class in college, and I wasn't really sure what I wanted to do. It just happened that I joined the team right before we started the big transition to .NET, and the rest was history. That being said, dedication, hard work and being willing to stick it out through some tough times also played a part. The process of moving from VB6 to VB.NET was definitely a long and difficult process.

I think also that a lot of my career can be explained by the fact that: a) I can't leave well enough alone, b) I don't realize how difficult something might be before I agree to do it and c) I hate to leave things unfinished. As a result, I tend take on new, big challenges without thinking much about whether I can actually do it. Then once it becomes clear that I'm in way, way over my head, I just keep pushing along until I come out the other side. So far, this seems to have been a successful model for career advancement. It also helps that I enjoy explaining things to people, which is where the writing comes in. Or maybe I just like to hear myself talk. Either way, it certainly boosts the attention meter.

DevSource: What's the most important thing you learned in school?

Because I started programming at 10 years old during a time when computers hadn't penetrated that far into schools (when I was in high school, they were still teaching "typing" on manual typewriters!), most of the really important stuff I learned outside of school. That said, the "data structures and algorithms" class I took, way back when, has been invaluable over the years. Not so much because I remember everything I learned (I can always look that stuff up!) but because it taught me how to think like a computer scientist. I'm pretty convinced that 90% of programming is learning to think the right way about problems and the other 10% is actually knowing stuff.

DevSource: What's the most important thing you learned outside of school?

Never plug a peripheral card into a computer while the computer is on (which I learned the hard way one Christmas many years ago).

Other than that, the most important thing I've learned is that school learning is no substitute for real-world experience. You have to have a grounding in the fundamentals (see previous question), but beyond that, you really need to be able to think for yourself and learn what you need to know as you go along. Programming moves so fast, what you learned yesterday may not apply tomorrow.

DevSource: The last book you read.

I hate to admit this, but it was The DaVinci Code. My wife and I were flying somewhere and it was a quick, easy read. The historical bits were interesting, but I didn't think it was all that great.

Now, if you had asked "the last book you lugged across the country with you on a plane but didn't read?" the answer would be Quicksilver, by Neal Stephenson. (Of course, nothing compares to the copy of Idoru by William Gibson that I carried onto so many plane flights but didn't read; that book practically had its own frequent flyer account!)

DevSource: The last song you listened to.

Absolutely no clue. Probably something by R.E.M. Growing up in Durham, North Carolina during the 80s, I seem to have this strange affinity for rock groups from Athens, GA.

DevSource: Personal obsession. Or, what do you collect?

No big shock, I'd say my personal obsession is programming. When my direct coding responsibilities eased off at work in favor of design and management stuff, I started picking up personal side programming projects because I couldn't stand not to be writing something.

As for collecting, I collect two things: electronic gadgets that are destined to become obsolete, and comic books. Besides being the proud owner of an Apple Newton, I also own an original Palm, a Magic Cap device, and more Windows CE devices than I can count. As for comics, I mostly collect the comics (excuse me, "graphic novels") of Alan Moore. I was very lucky to be turned on to Moore early on by a helpful comic store owner, so I've got most everything he's written. My favorite is probably V for Vendetta, although Watchmen is a classic as well. His newer ABC stuff is still good, but not as focused.

DevSource: What do you think is wrong about the way that software development is done nowadays? What's the problem that nobody has solved?

The problem that nobody's solved is that fact that humans have to do it, and humans innately tend to make mistakes. On the other hand, I don't know that computer-written code, even code written by very intelligent machines, would be any better. In fact, I seriously doubt that we'll ever find a revolutionary method of eliminating human error in programming. Instead, it'll be the usual hard-won incremental improvements year in, year out that will someday converge on a more reliable way to develop software.

One other thing that annoys me about the software development industry is the common emphasis on methodology over individual skills. Methodologies — such as test driven development, extreme programming, object oriented programming, etc. — all bring something good to the table, but we often lose sight of the fact that they're all means to an end, not ends in and of themselves. A lot of people seem to end up wasting a lot of time worrying about the finer points of some methodology or another, rather than thinking about whether or not it's going to help them personally write better software.

DevSource: In the years that you have been a developer... what are the biggest changes you've seen? What's totally different about the development process now? And what has stayed the same? What do you wish had changed, that hasn't?

Well, I've been programming for 24 years now and the better question is: what hasn't changed? Pretty much everything that goes into being a programmer has gotten bigger, better, and more advanced over time. In the past 25 years, we've gone from the equivalent of banging rocks together to rocket ships. Anytime I'm tempted to start down the nostalgic road of "well, when I was a kid, I had to walk three miles to school through snow with no shoes..." I just stop and think about what it was like to develop software without a debugger of any kind. And then I think, "The old days were not better."

I think the single most important change for developers in the past 25 years has been the improvements in IDEs and debuggers that automate a lot of the programming and debugging tasks that people used to have to do laboriously by hand. It is so much quicker to work today than it used to be. But I still want it to be even faster. As great as our IDEs and debuggers are, they're still pretty stupid about understanding the programs that we're writing or debugging. More intelligent IDEs and debuggers should take on even more of the burden of programming than they already are.

DevSource: You've worked on a lot of things. What have you personally accomplished that you're most proud of?

There is nothing more satisfying to me than that moment when a new idea or concept suddenly becomes clear for the first time and I sit down and express it in code. In that moment, it feels like everything in the world has just snapped into place. I've very proud of the big stuff that I've done—Access and Visual Basic are both great products—but it's the little day-to-day achievements like that that make it worth coming into work every day.

Also, and this may sound weird, I also find it extremely satisfying to take a crappy piece of code and rewrite it into a clean and elegant piece of code. I guess I'm just one of those people for whom cleaning things up is therapeutic. In fact, I spent most of yesterday doing that to some obscure piece of the Visual Basic compiler and it felt great!

DevSource: What about programming do you hate? What about the development process makes you think, at least for a moment, that perhaps this would be a good day to de-frag your hard disk instead?

That's easy: I would rather do almost anything except test my code once I feel like I'm done with it. Testing positively bores me to tears because I like writing the code, not trying to break it. The worst part is that you absolutely have to do it if you're any kind of self-respecting developer.

At Microsoft, there always tends to be a bit of rivalry between the development and testing groups because development is always trying to fix the bugs and testing is always trying to come up with new ones. But I have nothing but the highest respect for someone who actually enjoys doing nothing but sitting around and trying to think of clever ways to break code. It's something that I do, but I certainly don't enjoy it and if I could avoid it, I would.

DevSource: A few days ago, on your blog, you admitted, "RDBMS access is intrinsic to modern application implementation. It's the second part of Joel's statement - the supporting it part - that's the hard part, though." Okay, so maybe you've just given this item to your Muse and said, "Come up with something good, and wake me at 3:00am when you do." But have you come up with any, er, musings? What makes this such a difficult problem to solve?

The sad part is that in many ways the problem is historical rather than technical. Database systems and operating systems just developed in two very separate worlds and never the twain shall meet. Given that, it's no big surprise that languages designed to program against the former (i.e. SQL) don't play all that well with languages that are designed to program against the latter (i.e. VB, C++, C#). Over time, the walls between the two worlds have grown higher and higher. How do you break them down now without breaking the whole world? That's the real question.

I think this problem is going to take a long time to solve, because it has to be solved at a bunch of different levels, not just at the language level. The best thing that we can do as language designers is start to think about how to introduce database concepts into our languages in the most natural way possible and then use that to drive database systems and operating systems closer together.

Which, I'm afraid, is still just a lot of hand waving. The real problem is that this is not just some Gordian knot that we can cut through with one stroke. It's going to require long-term incremental changes. Can I get back to you on this in a few years?

DevSource: VB.NET makes a lot of changes, at least from the old school VB programmer's point of view. And while developers are adopting it, plenty of VB guys are holding back. (They keep saying they'll start using VB.NET, Real Soon Now, but statistically few of them get around to it.) What do you think is keeping everybody from grabbing at VB.NET as if it were free ice cream cones on a summer day? What has to change: the development environment, the programmers' attitudes, something else?

There are two kinds of upgrades in software: no-brainers and big leaps. No-brainer upgrades are those kinds that, you know, pretty much work the same way the last one did and add some nice features here and there. You can take whatever installation you've got and upgrade and nothing major is going to happen, so why not? It's a no-brainer.

Big leaps, on the other hand, tend to break things and have difficult upgrades because they're such a big change from what came before. You can't just take what you've got and upgrade. You have to carefully consider what the costs of making the upgrade are going to be, and how much work you're going to have to do to get there. This makes most people very cautious and unwilling to make the leap, unless they see overwhelming justification for doing so, which is an entirely rational response.

In the case of VB 6.0 to VB.NET, VB made a very, very big leap. For Web developers, the advantages of programming ASP.NET over programming regular ASP were so incredibly compelling that they had very little trouble justifying the leap. But for smart client developers, and there are a lot of VB smart client developers, the advantages of programming in VB.NET over programming in VB6 were more incremental and this, understandably, has made some of them slower to make the leap. We're going to be doing some very exciting things for smart client developers in Visual Basic 2005, but I think where things are really going to change is when Longhorn (the next major Windows version) arrives. One of Longhorn's primary missions is to revolutionize the smart client experience, and that's the point where smart client developers are going to say "Hey, I really need to get in on this, how do I do it?" And then I think they'll make the jump without even thinking too much about it.

DevSource: What's new and exciting in Visual Basic 2005? Will developers experience the same level of change?

No, the transition to Visual Basic .NET 2002 was a one-time-only thing that allowed us to make the big leap from COM to .NET. If we've done things right with .NET, and I think we have, developers won't have to experience that level of change again.

That said, there is going to be a lot of cool stuff in Visual Basic 2005. The IDE experience is going to be much, much improved. The biggest feature there is the return of one of the most missed features in VB .NET, Edit and Continue (a.k.a. "the ability to edit my code while my application is running"). We're also doing a lot of work to help people correct common coding errors, and giving them easy access to a large library of code snippets that should make solving common programming tasks a lot easier. And we're adding a new namespace, My, that contains quick shortcuts to the most useful features of the huge framework that we ship as a part of .NET.

On the programming side, we're adding major features like generics and operator overloading. While they may sound like features that only advanced programmers would care about, the fact that they're going to be used in the .NET Framework and in Longhorn means that VB users will find themselves taking advantage of them almost without even realizing it.

Chat with Paul, for the next few days, in our discussion forum.