First Looks

On the State of VS and .NET

The second part of VSM's Q&A with Richard Hale Shaw discusses how -- and whether -- developers should keep pace with new technologies.

• By Richard Hale Shaw
• 11/01/2008

VSM: I've heard you make the point that developers should explore all technologies as they come out. Of course, the flip side of that is the pace of change, and how can developers possibly hope to keep up. How do you choose which technologies you take up, and which you let go?

RHS: You have to evaluate new technologies, not simply jump on board with them. For example, I've been teaching people about Windows Communication Foundation [WCF] since it came out, but I've done so with a lot of caveats, because the toolset for WCF has been pitiful. You could say this in general about Microsoft developer tools: Microsoft has a tendency to expend more energy, effort, and QA on the underlying technology first, and only secondarily on the toolset created for developers to use that technology. I've had people at Microsoft say to me: ‘We're always getting beat up in the press about the quality of our tools, relative to our competition.'

VSM: Do you think the criticism is fair?

RHS: Well, Microsoft has a point, I think. If you look at the IBM and Java communities, their underlying technology doesn't come anywhere close to .NET. .NET is vastly superior.

But they have a lot of great tools over there.

Richard Hale Shaw, founder of Richard Hale Shaw Group and a conference chair at 1105 Media Inc.'s VSLive!

WCF has been a good example of this issue. WCF is a great technology for building services, but the toolset hasn't even been as good as what you had with ASMX, in many ways. The toolset for WCF got a little better with VS 2008, but it's still kind of goofy. You should be able to generate the test page with links to invoke the methods, as you can do with ASMX. They threw in a hosting tool for hosting and testing services, but it strikes me as awkward and more work to use than it should be.

Acknowledging the limits of ASMX, you should be able to do at least as much with WCF. But here we are 18 months later -- WCF is no longer an add-in for VS, it's a part of VS, and the toolset is still not there. I shake my head at this. Then I hear Microsoft personnel complaining about WCF not penetrating the market the way Microsoft thinks the technology should. But there's a reason for this. If the toolset were better, developers would be far more inclined to at least experiment with WCF.

VSM: So there's an issue with the robustness and completeness of some of these tools when Microsoft releases them.

RHS: Yes. Getting back to your earlier question and which technologies you should take up, you have to recognize that these new technologies aren't necessarily mature when they're first released. LINQ is the exception, not the rule: If you look at a technology like LINQ, it appears as though it entered the world fully grown and complete, like Athena from Zeus' head. There's a lot Microsoft can do to extend it, but out of the box, it's an extremely capable technology. On the other hand, there are others -- like various releases of ASP.NET over the years -- where you just have to wonder: When are these technologies going to be updated to the point where they feel mature, where you're not inventing lots of workarounds to utilize them?

This, by the way, is probably a good gauge of a new technology's maturity: Can you use it as-is, or do you find tons of deficiencies -- and lots of solutions that are being devised to work around the deficiencies?

This realization comes from someone who spends a lot of time with these technologies. I understand that it's tough to do this for a developer in a small company who doesn't have a lot of time. It's also tough for developers in larger companies who must investigate a technology for the rest of the team, and then share that knowledge with other team members. There's no easy way to do this. I think you just have to resort to a lot of different sources of different information.

I should add that people do often ask me: How do I keep up? I think you have to define your own techniques for doing so, and -- most importantly -- ignore the noise. What marketers and bloggers say is hot isn't likely to be important in six months.

VSM: You mentioned how some technologies seem to be introduced as viable out of the box, while others fall way short. What are some of the reasons you think we see such disparities in the initial release quality of various technologies?

RHS: Some of these technologies are introduced with what seems like a lot of thought on the part of the party that introduces them -- LINQ, for example. But then there's a whole bunch of other stuff where it appears that no one has given any thought to the real-world implications of the technology being released. Case in point: Web site projects in ASP.NET, which I think was a fantastic waste of time for many of us.

I always applaud it when a particular team takes the time to get the input from the field instead of just rushing a given technology out there. Some of the teams at Microsoft seem to have a better track record than others. For example, they seem to have the vision to see real-world problems and to find solutions for them, whatever the level of feedback they receive from the field. With other teams, it's as if no one ever asked anyone else whether a given feature would be a good idea.

While I'm pointing fingers, let me fill in the blank in regard to ASP.NET. I'm very skeptical of this part of the framework, and I personally think it has a poor track record. The ASP.NET team has never dealt with deficiencies that have been a part of ASP.NET from the beginning, and while it continues to evolve, I think each new release tends to miss an opportunity to address other problems that Web developers using ASP.NET are facing. For example, there's little thought given to reusability or type safety in ASP.NET. Also, consider the case of re-using Web page content -- I don't think Master Pages are a good solution at all -- or re-using custom controls [such as] ASCXs. Or treating URLs/URIs as objects; way too much of this technology relies on System.Object as a type. I mean, isn't this why Generics were invented? Way too much of this technology lets you use strings as parameters, where string contents could be mapped to anything.

Unlike the rest of the framework, in ASP.NET it's easy to do the wrong thing, and often difficult to do the right thing. It's possible that some of the new features in the MVC Framework will resolve some of these issues, but it's still a bit of a moving target. If you look at the rest of the framework, however, it's so tight. Some parts of it are amazingly tight, absolutely bulletproof. You look at ASP.NET, on the other hand, and it's just, well, a mess. By the way, I'm giving a talk on exactly these points -- with some guidelines, workarounds, and best practices -- at VSLive! this fall.

Read the first half of this interview in the October 2008 issue.