For a long time, I’ve been trying to write an entry entitled “I Hate Mort” that captures everything that I think is wrong with the current “Mort, Elvis, Einstein” taxonomy of developers that Visual Studio uses. And, for a long time, I’ve been failing miserably. I think it’s that I tend to want to be very fair-minded on the subject—by and large, people are extremely well-meaning when they talk about Mort and Visual Basic, and I feel bad bad-mouthing something that a lot people have invested a good chunk of thought into. However, Scott Bellware has no such qualms:

The Microsoft developer personas that include Mort, Elvis, and Einstein are ultimately an ethically bankrupt mechanism to pigeon-hole software developers into the kind of overly simplified categories that a typical marketing staffer is comfortable with.  While intended to help this particular parasitic segment of the corporate world to behaviorally model the psychological predispositions of software developers at their work in an unrealistically simple way, it has instead turned into a system of limitations that developers have begun to impose upon themselves to the detriment of the advancement of software development practice and industry.  It appears to be a bid by developers to rid themselves of the capacity for rational thought in favor of tribal identification with corporate brands and software rock stars.

Now, I don’t agree with everything Scott has to say in “Mort or Elvis? A Question for a Bygone Era”—he definitely has some specific axes to grind that I don’t—but I think he does capture some of the essence of the problem with the personas. The fundamental error I think most people make with the personas is that they see them as mutually exclusive rather than points along the experience spectrum. When I’m working on the VB compiler, I’m definitely an Einstein, thinking at a very high level. When I’m working on stuff like the VBParser sample, I’m generally an Elvis, thinking at a somewhat lower level. And when I’m writing batch scripts or ad-hoc data analysis tools, I’m definitely a Mort, hacking around to figure out what I’m trying to do.

The point really is that most people are usually Mort, Elvis and Einstein all at the same time, depending on what they’re doing. And by building tools that target one or the other, we’re artificially segregating people’s work into buckets that don’t really map onto their daily lives. (I would also argue that the past several releases of Visual Studio has emphasized some personas over others.) Finding a way to better serve people as they move through the flow of the day-to-day work is something that is need of some serious attention. And it’s something that VB has historically been very preoccupied with. So… what to do about it? That’s the question, isn’t it? Nothing to talk about yet, but it’s fermenting…

At the end of his entry on the concatenation operator, Bill observes some strange behavior around types that have a user-defined conversion to String but can’t be used with the concatenation operator. This is actually a design bug in our operator overloading resolution logic that we’re planning on fixing, since it won’t impact compatibility at all. To quote almost verbatim from the preliminary spec I wrote on it:

Consider the following program:

The first expression fails because of a problem in the way that the operators that participate in operator resolution are chosen. Given an operation on two types, X and Y, the operator that is used is resolved as follows:

• If X and Y are both intrinsic types, the operator to use is determined by the operator tables in the language specification.
• Otherwise, the user-defined operators in X and the user-defined operators in Y are collected together and overload resolution is used to determine what the best fit, if any, is.

When you mix user-defined and intrinsic types, however, the algorithm can fail unexpectedly. When interpreting the expression C & String, the second bullet point is applied since both types aren’t intrinsic. Since neither type has a user-defined & operator, a compile-time error is given.

(C# doesn’t have this problem because they don’t distinguish between user-defined operators and intrinsic operators: they collect all operators together and throw them into overload resolution. We can’t do this because our intrinsic operator resolution rules do not conform to standard overload resolution rules. According to standard overload resolution, 1 / 2 should result in a Decimal value, but we change the rules to make this result in a Double value. This means we can’t just throw the standard operators into overload resolution into the second bullet point above, because then something like X / Integer would result in Decimal while CInt(X) / Integer would result in Double.)

To solve this problem, operator resolution will pre-select a single intrinsic operator to participate in overload resolution. Thus, the rules for operator resolution will be expanded to:

• If X and Y are both intrinsic types, look up the result type in our operator tables and use that.
• If X is an intrinsic type, then
• Collect all of the intrinsic types that Y converts to.
• Choose the most encompassed type, T, from the list. If there is no single most encompassed type, then we don’t consider an intrinsic operator.
• Lookup up the intrinsic operator for X and T, and call it O. If there is no intrinsic operator defined for those two types, then we don’t consider an intrinsic operator.
• The set of operators to be considered is all the user-defined operators in Y, plus O, if it exists.
• If Y is an intrinsic type, then perform the same steps as for X (obviously, both can’t be intrinsic types at this point).
• Do overload resolution on the set of operators to be considered.

This algorithm would appear to give us what we want. It’s the same basic steps we go through today, with the addition of the “narrowest” intrinsic operator possible if one of the types is intrinsic. It should also solve Bill’s problem.

Over on his blog John Montgomery shares how some of Microsoft’s internal research puts the lie to the old canard that VB programmers aren’t as smart as other programmers. A short quote:

If you ask VB developers how much education they have, about the same have college degrees as C/C++ developers (we ask what their primary language is and cross reference by level of education attained), and only negligibly more C/C++ developers have graduate degrees. More than that, more pro developers who primarily use VB say they have an undergrad CS degree than pro developers who use C/C++ primarily (though more C/C++ primary devs say they have an engineering degree). In other words, C/C++ pro devs are more likely to have an engineering degree than VB devs (it’s outside the margin of error, but just barely).

Longer entry is here.

I was on a thread today where a VB MVP asked if VB was ever going to integrate regular expression-type functionality directly into the language to make it easier (and more comprehensible) to work with strings. The immediate reaction in my head was, “Well, it’s in the pipeline, but no telling if it’ll ever come out…” Which bears a little explanation…

The traditional model for software development at Microsoft is something I’d call “punctuated insanity.” That is, you start a product version by running around like a chicken with your head cut off, trying to come up with what you think you should do in that version. Because you only just started thinking about what you think you need to do, the schedule goes through a phase of rapid expansion as people try and flesh out the initial ideas (which always cost more the more you think about them) and try to jam in all the other good ideas they had (because they know it’s going to be another couple of years before they’ll get to put new stuff into the product again). This is the “insanity” phase of the product, where reality takes an extended vacation and the product plan goes all over the place.

Usually, after some period of insanity, reality (a.k.a. management) comes back from its vacation, finds the house trashed, the fridge empty and the car at the bottom of the pool and freaks out. At this point, some combination of feature paring and schedule slippage happens as the product plan slowly starts to come back to something that is actually shippable. (The product likely goes through several rounds of this before making it to RTM.)

The problems with this model are pretty obvious on the back end—schedule slips and feature cuts are never a happy thing from either the company’s or customer’s perspective. But I think more damage is done on the front end of things. Because planning only ever happens at the beginning of a product cycle, our ability to react to ongoing changes in the market place is seriously compromised. Even worse, because all planning happens in a very short burst it’s very likely that any sufficiently complex feature isn’t going to get the kind of design time that it really needs. Put another way, features only get designed once and you have to hope the feature is right, because you have only a limited ability to react to external and internal feedback once you get the feature finished and you can actually use it.

There are enough obvious examples of this process in action that I don’t even need to bother to point them out.

Much better, when you can do it, is the “pipeline” model of software development that you see much more often in our web offerings. In the pipeline model, you’re never working on just one release. While the main bulk of the team may be working on the next release, you’ve always got some number of people working on features that are further back in the pipeline. What this means is that, first of all, you have people who are actively looking ahead beyond the current release and can start reacting to changes in the marketplace before you’ve finished the current version. It also means that more complex features can have longer “bake” times in the pipeline, allowing teams to try stuff out, see how it flies and discard or modify designs that don’t work. The result should be a more complete, more polished set of features when they finally reach the front of the pipeline (assuming they aren’t discarded entirely before that time).

LINQ has so far been a good example of pipelining in action, and it’s something that we’re actively trying to adopt within the VB team itself, at least on the language side. Regular expressions has been one of those things that have been hanging out there on the “consider one of these days” list for a long time. My hope is that as our pipeline gets going, these ideas will finally get their chance to be tried out and then either discarded or moved towards actual implementation. I can’t say whether regular expression integration will be a good idea or not, or whether it’ll ever show up in VB. But with a more forward-looking approach, I’m hoping we’ll find out…