Eric Lippert astutely pointed out a hole that I consciously left in my discussion of black hole projects – namely, that they sometimes succeed. I left that part out because I figured it probably merited a little discussion of its own and I didn’t want to complicate the whole “black hole” narrative.
Eric’s completely correct that you could argue that .NET was a black hole project, albeit one that succeeded. It managed to hit most, if not all, of the bullet points I listed, including the last one (I started work on what would become VB.NET in mid-1998, after all, and some people had been working on it for several months by that point). I distinctly remember the first meeting I had with Brian Harry where he outlined a proposal for what would become the metadata engine in .NET. I thought to myself “this guy is completely crazy” because of his grandiose goals. A few months later, I remember sitting in a co-workers office talking about the emerging .NET strategy. “Do you think this thing will actually fly?” she asked me. “I have no idea.” I replied, “I give it about 50/50 chance. I guess we’ll see.”
However, I disagree with Eric a bit that it’s extremely hard to distinguish between a black hole project that’s going to impode and a black hole project that’s going to succeed. I think there are some traits that distinguish the projects that have succeeded. I’m less certain about them because 4 out of 5 black hole projects have failed, so I have less data to extrapolate from, but here’s my take on it…
The number one, no question about it, don’t leave home without it, trait of succesful black hole projects is:
- Despite having grandiose goals, they are fundamentally a response to a serious and concrete competitive threat.
If .NET had started just as some abstract project to change the way that people program, then I’d be willing to wager that it would have gone down in flames at some point. What kept the teams focused and moving forward was the fact that, let’s be honest here, Java was breathing down Microsoft’s neck. Without that serious competitive pressure, odds are pretty decent that the .NET project would have eventually collapsed under its own weight because we wouldn’t have had the kinds of checks and balances that competition imposed on us. But the reality of needing to compete with Java helped keep our eyes on the prize, as it were, and counterbalanced the tendency of black hole projects to spin out of control.
Some other traits of successful projects are:
- They tend to be led by people who, while they may be fantastically idealistic, are ultimately realists when push comes to shove.
- It also seems to be vitally important that the project leadership be very, very technical. This allows them to stay in touch with what is actually happening in the project rather than having to rely on status reports (which are usually skewed in the optimistic direction) and allows them to ask the hard questions.
- Hidden under the absurdly grandiose goals must be some set of real life problems that real life customers need solved.
I think what I’m starting to get at is that the line that divides success from failure is ultimately how in touch with reality the project team is. The Catch-22 is that to make large leaps, you often have to unmoor yourself a bit from reality so that you can see beyond what is into what could be. But once you’ve unmoored yourself from reality, it’s easy to go all the way and completely lose touch with reality. That’s the point at which things start to spiral out of control. The projects that succeed, in turn, manage to keep one foot in reality at all times. This keeps them from going absolutely insane. And, I think, it’s not as hard as it seems to get a sense of whether a particular project has one foot in reality or not. Usually, all you have to do is talk to a cross-section of the people working on it. They’ll know pretty well what the state of the project is.
I should close by saying my intention wasn’t to knock ambitious projects. I think they’re totally necessary to help our industry make those big leaps forward. It’s more of a question of how people go about doing ambitious projects that I sometimes have a problem with. Projects that think big but try as best they can to stay practical are really the best kind of projects to work on. I can’t say that every moment of working on .NET has been fun, but overall it’s been a wonderful experience and one that I’m very glad I got to be a part of…
I think the cool thing about Microsoft is that it can afford to take on black holes, and once and a while, produce such awesome diamonds, such as .NET.
Has .NET after all this time done any harm to the Java dominance on the server-side business applications market? Facts are that .NET is not being used as extensively as one expected in front-end applications, and did not "compete" with Java (or other technologies) in the back-end front, being used mostly as an "upgrade" for ASP applications. In this sense, .NET is big market failure and thus it *is* a black hole project.
I fail to see how dotnet is a "big leap forward" compared to Java. All you did was copy existing technology, making some evolutionary improvements at places, while at other places making some steps backwards in dotnet compared to Java.
<![CDATA[No offense, Loren & J.Holmes, but I'm not sure why you feel the need to attack .NET when the original post didn't disparage your technology of choice. Both seem to work fine for my line of work.]]>
<![CDATA[Paul, That’s interesting. Aside from the point of the "black hole" thing, a few months ago I wrote this: http://www.vbbox.com/blog/2004/05/net-that-old-technology.html I guess this confirms my suspicions =)]]>
<![CDATA[Loren and J.Holmes, Oh good, a religious battle over Java and .NET! .NET is a leap forward for at least a couple of reasons
– attributes in syntax.
– integration with platform and pre-existing apps (like COM, or just plain c/C++ dlls)
– multi-language model
– advances in code-access security This stuff was not available in the same way, in anything prior, including Java. Sorry if you don’t agree, but being able to embed .NET logic into an Excel spreadsheet is very important. Re-using C++ logic from other languages is important. This stuff wasn’t possible with Java. Still isn’t. (don’t say, "JNI" – it is practically speaking, useless) The statement that .NET has failed in the market, seems to be overstepping a bit. The goal of .NET was not to destroy Java, so concluding that .NET failed because Java is still here is specious. The goal of .NET was to enable devs who wanted to target Windows a better way to do it. (and secondarily, to entice devs to target Windows). And at this it has succeeded, academically speaking. .NET is better, easier, more accessible than COM. As for adoption, .NET usage is good, higher than Java in at least 4 recent studies I know of (BZMedia, Gartner, Forrester, and Evans, all from 2004) . So, .NET is easier than what came before, it is being adopted and usage continues to rise. This is not a failed technology.