Monthly Archives: November 2004

Software patents

In the wake of the IsNot patent brouhaha, aside from the “you are scum” comments, people have had several reasonable questions about my own feelings about the situation. So let me pause and talk about software patents for a moment. Lest there be any question about this, what follows are my own personal feelings about the matter and have nothing to do with official Micorosoft policy.

Personally, I don’t believe software patents are a good idea. I realize that algorithms lie in that grey area between a mechanical process (which is patentable) and an abstract idea (which is not), but at a purely practical level I think that software patents generally do much more harm than good. As such, I’d like to see them go away and the US patent office focus on more productive tasks. I have nothing but contempt for any company that tries to use patents to achieve what they could not through purely competitive means. This includes Microsoft, should they ever choose to do so or have they ever chosen to do so. (I’m not aware of any such situation, but I’m hardly omniscient.)

However, software patents do exist. So while the good fight goes on to get rid of them, I also believe that it would be dangerously naive to not play the game as best we can in the meantime in as principled a way as possible. There are a lot of people who would love nothing more than to just take a piece out of Microsoft either because they can or because they want to get rich and not for any better reason than that. I’ve been around long enough to see the kind of trouble that patents can cause us, and so I believe the best defense is a good offense. While I don’t believe in using patents in an unprovoked way, I do believe in having a robust patent arsenal with which to defend ourselves should someone get it in their head that they want to hold our products hostage for money or just to cause trouble.

One of the most unfortunate aspect of the software patent system is that there is a distinct advantage, should you have the money to do so, to try and patent everything under the sun in the hopes that something will stick. If someone has a patent on “a biological system used to aspirate oxygen gases to fuel biological processes” (i.e. lungs), I wouldn’t be surprised. (If there isn’t, no fair submitting the patent before me!) This is bad both because it jams up a system that’s not really equipped to handle software patents well in the first place and because it increases the likelihood of broad, random patents slipping through the system. Microsoft has been as much a victim of this as anyone else, and yet we’re right there in there with everyone else, playing the game. It’s become a Mexican standoff, and there’s no good way out at the moment short of a broad consensus to end the game at the legislative level.

So that’s how I feel about software patents in general. As far as the specific IsNot patent goes, I will say that at a personal level, I do not feel particularly proud of my involvement in the patent process in this case. Beyond that, there’s not much to say: many comments addressed legal questions which I am woefully unqualified to comment on and for which speculation would be very unwise on my part.

Welcome Slashdot…

So every time someone whose blog I read would get Slashdotted, I would wonder to myself, “I wonder if this will ever happen to me?” And then I would start speculating, “Hmmm… If so, I wonder what kind of thing I’d have to do to get myself Slashdotted…” Well, now I know: have Microsoft submit a patent for the IsNot operator, listing me as the principal inventor. Wonderful. Glad to see it’s over something that I can be really, really proud of…

(It’s not a full Slashdotting I suspect, because the blog is only mentioned in the comments, not the main entry, but even a tertiary flood is interesting…)

Updated: Corrected the misuse of “principle” when I meant “principal.”


The Tyranny of the Suite

Another common comment around refactoring has been: why do we have to wait for a whole other release to get refactoring? Why can’t you just do the features and then ship them when they’re ready?

The answer, for the moment, is that we are subject to the “tyranny of the suite.” Which is to say, we are so tightly bound to the rest of the suite of products that we ship with (C#, C++, J#, debugger, IDE, SQL Server, CLR, etc.) that it is extremely difficult for us to ship separately from the rest of them. In effect, it’s like we’re running some freaky twenty person version of a three-legged race. Because all our legs are tied together, nobody can move forward unless we all do, and coordinating everyone to step at the same time is a major undertaking.

This binding was absolutely necessary to ship the initial version of .NET because it was a v1.0 product and we needed every piece of the puzzle in place to make the system work. Now that we’ve moved beyond that, though, it does seem like it should be possible to move more towards a “ship early, ship often” strategy that allows individual pieces to innovate separate from the rest of the suite. Some things, like generics, would still require simultaneous work across the entire stack, but other things, like refactoring, could be done in smaller, incremental releases.

Now, whether this actually happens remains to be seen. A lot of the machinery that goes into release management is shared across the suite, and it’s not clear how possible it is to disentagle it all. Plus, the butterfly effect holds: small, out-of-band releases increase the test matrix and make it more likely that, say, a minor VB release could conflict with a minor ASP.NET release in ways that were very unfortunate.

Anyway, I think what can be said best is that we are always looking to improve our release strategies and get new features into the hands of our users as soon as possible. Time will just tell.

Refactoring and drafting, revisisted

In response to my entry on refactoring in VB 2005, some have asked why VB couldn’t take advantage of C#’s work on refactoring the same way that C# took advantage of VB’s work on Edit and Continue. I anticipated this would come up, and the answer is that some features are subject to drafting at the current time and some aren’t.

Edit and Continue is a feature that spans the compiler, the debugger and the CLR. As such, work done in the latter two areas can be applied across all the languages that want to take advantage of Edit and Continue. Refactoring, on the other hand, is a feature that is currently implemented entirely within the compiler. Thus, there’s no opportunity for taking advantage of the work that other teams have done on the feature.

Now, one could certainly imagine a world where it might be possible to share the work on refactoring across the languages, but we’re just not there yet. Refactoring requires an intimate understanding of the structure and meaning of the code that’s being modified, which is why it’s currently implemented as a part of each language’s IDE component. If there was an abstraction layer, however, that could abstract away the different syntax and semantics of the languages to such a degree that one could manipulate C# and VB code in a language-independent way that preserved semantics, then common refactorings would be possible. At the moment, though, neither VB nor C# is architected in this way.

Given some of my experiences with the CodeDOM and WinForms designer trying to do a much simpler form of this, I’m not entirely sanguine that such an abstraction layer is possible. Perhaps some of the third-party refactoring tools will prove me wrong on this. It’s something that we talk about and will think about as we move past 2005, but for now each language is on it’s own as far as refactorings…

Refactoring: Not for VB 2005 (for the most part)

The problem with making confident predictions about the future is that time has a way of making a liar out of you despite your best intentions. As Steven posted Friday, VB will not have any refactoring features beyond “rename symbol” in VB 2005. This was an extremely painful cut and one that we tried to move heaven and earth to avoid, but in the end we didn’t feel we could get the features into the product in a high-quality way without causing serious risk to our shipping goals. Balacing the cries for refactoring against the cries for us to ship as soon as possible was difficult, and we really regret the fact that it ain’t going to happen this time (for the most part… it’s not like rename symbol is chopped liver or anything!).

On the other hand, it does mean that we get a while longer to have lots of colorful, humorous arguments about whether we should have a “Refactoring” menu in VB or not. Oh, joy…