VB.NET in a Year

I've been working with VB.NET for a little over a year now. When I first started my job, I didn't know or care what language they used. I was quite surprised to see a software shop use VB. I thought that stuff had died a long time ago. Well, after a year, I think I've learned most of the language itself. There's still much to learn about the surrounding systems, but I'm pretty comfortable with the core of the language.

What have I learned about VB.NET? It's not really that bad. Let me go over a few pain points and then explain what I like about it.

Pain #1: No extension methods on objects of type Object. This is very annoying. We use ADO.NET extensively, and those things are not typed. If I request an INT NULL from the database, I want it back as a Nullable(Of Integer). However, it comes back as an Object which might be DBNull.

That's not a major problem. I can write an extension method that will do the conversion for me. Well, it turns out I can't. VB.NET just won't apply extension methods to Object. C# will do it just fine, but VB.NET won't. As a result, I can't use an extension method. I have to call the function on this thing instead of treating it as a function of object.

Pain #2: Really long closure syntax. I use the method form of LINQ extensively, so it's really annoying when 1/10 of my code is "Function (...)". C# makes it nice and easy. Who decided that VB.NET has to be wordy?

Pain #3: Tuple support. One of my favorite languages is Python. If I want to pass back two objects, I can pass it back as a tuple and assign it to a tuple. In VB.NET, I need to create a class or modify my parameters. I really don't like modifying parameters, and I am too lazy to create types for everything.

Anonymous types work pretty well for closures, but they don't work across function boundaries. If I return it, it becomes an Object in the caller. What happened? The compiler knew it had two fields before, how come it forgot it?

Say I do manage to get it back. How do I assign the fields to my local variables? I miss "(a, b) = (b, a)".

Pain #4: Generic Constructors. Say I have a generic class where the type is determined by the value passed into the constructor. In the new statement, I have to specify the type of the class even though the compiler can infer it from my argument. This is all good until I have to pass in an IDictionary(Of String, IDictionary(Of Integer, Integer)). That's way too much typing for something the compiler should do for me.

Pain #5: No dedicated dictionary syntax. I really want x = {a: 3, b: 4}.

Pain #6: (New Foo).Bar doesn't work. The compiler forces me to assign New Foo to a variable before I can call Bar on it. very annoying. I don't need to keep it. I don't want to assign it to a variable.

Pain #7: No macros. I want at least C style macros if I can't have Lisp style macros. I get neither. Awesome.

After a year, certainly there are things I like about VB.NET. What do I like about VB.NET?

Plus #1: IntelliSense. This is more about Visual Studio than VB.NET, but Visual Studio is one of the best parts about VB.NET. Not having to remember property/method names is awesome. Not having to remember the methods of types is also amazing. What can I do with this thing? Type '.' and IntelliSense will tell you right there. And it's always right. It never gives extra suggestions nor misses anything you haven't used before.

Plus #2: Edit and Continue. Even though I can't edit and continue anonymous methods, it's still magic.

Plus #3: Optional parentheses. I used to think this was really weird, but now I like it. This makes me type AddressOf often, but I think the parentheses I've saved makes up for the AddressOf that I have to type once in a long while.

Plus #4: CLR library. There's a lot of good stuff built in already. No need to reinvent the wheel.

That's about it. In conclusion, the only thing that VB.NET has over C# is Plus #3. But as I look back over this list, most of the stuff I don't like only cost me a few seconds more of typing. Seeing as how I don't spend that much time coding anyway, it's actually not that bad. If I had a choice, would I choose to use VB.NET? Probably not, but it's not as bad as I had first thought.

Initial Responses to XP

Most of our development team has been introduced to XP now. We agree that there are a lot of changes that need to be made. Some of these changes are internal to the team, and some require external changes. The two areas that we think need to start first are the XP team and short stories. Our existing team is both a huge team and no team. We have about 15 developers, a few testers, a few product managers, a few account managers who act as customers, and a project manager. The people are very friendly, and everyone helps each other in whatever way possible. The environment is very good for a team, however, team is pretty spread out physically and logically. I am a developer, so I am most familiar with the developer's perspective. It takes a while to talk to the testers or product managers, and it is nearly impossible to get the attention of customers in a timely manner. Many developers are very busy with their stuff, so it is hard to get help when I need it. I often have to wait several hours to get answers. No only is the team busy with stuff, everyone is busy with different stuff. We strive for collective code ownership by having everyone work on various portions of everything. There is a significant amount of code, and it takes a new developer weeks if not months to know enough about the code to be productive. In an effort to improve our bus factor, we assign developers to various portions of the system that they are unfamiliar with. The main problem with this is that they are individually assigned to a half-year project with little involvement from other developers. At the end of the half year, the developer is familiar with the code, but no one else is. So instead of whole projects having a single expert, we have many portions of projects having a single expert. We haven't really improved our bus factor much. To address these issues, we are attempting to have smaller and tighter knit teams. We will have testers and customers be more involved in the development process to reduce the amount of time it takes to get answers. We will try pair programming to improve the collective code ownership. Personally, I was expecting a lot more resistance against pair programming, but most programmers don't mind it as much as I had thought. We have been trying it for a few smaller sessions and it seems to work pretty well. Surprisingly, this is probably going to happen first before other improvements. It is likely to grow organically as well. While we get the team together, we will also tackle the problem of slipping deadlines. We came up with a long list of things to do to fix them, but the best thing we are looking at is just to create smaller stories that give us more milestones. We are going to divide up the 2-12 week stories that we currently have into smaller 1-3 day stories that we will be able to better manage. So all in all, we are hitting quite a few bumps in the road to XP, but we're excited about what kind of changes we can make to our process.