This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: Was .NET a black hole project?
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
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...
Previous Topic
