Cutting the ties that bind: Why Microsoft will have to change the way it writes software

In software development, there's the concept of dependencies. Higher level things are generally dependent on lower level things. It's bad to have low level things dependent on high level things. Circles suck.

Everything in .NET is dependent on the execution engine, then the base class library is next in the stack, and so on, building up the familiar diagram:

But this is all pretty atomic. You don't get new framework version without a whole new drop of Visual Studio. It makes you wonder if VS was a little more framework generic, could we get certain framework enhancements (new class libraries, better JIT, etc.) sooner? Is the coupling here just too tight to be good for the customer?

But that diagram is really an oversimplification of what we have today. What we have with Whidbey, Yukon, etc, is more like:

(oops, forgot VSTS. Add another Product Grande with lots of little boxes inside of it)

The framework has gravity. It sweeps through space, and keeps accreting more stuff. Originally, smart device extensions weren't part of the framework/VS, but in v1.1, they got bundled in, and now the FX and smart device applications are forever stuck together. Same thing with mobile controls. With the next version, VS 2005 and SQL 2005 are locked together. This means that while I desperately want generics, If some feature of Business Intelligence (which I may never use) slips, then I have to wait longer for generics. The problem is that dependencies extend up and down the stack, and across very large products. Why should core features in the framework and BCL have to wait on the MS Project integration features of Team System?

Maybe Web Service Enhancements has it right. Forget about when VS ships, and release on your own cycle.

Maybe it makes more sense for the "major" releases to simply be an aggregation of the numerous SDKs that have shipped, kind of how Service Packs roll up the previous hot-fixes (and include some new stuff as well).

In other words, instead planning on rolling everything together, and then breaking it out as a last resort, plan on it being broken in discrete chunks, and if (for example) smart device can be ready at the same time as VS, they ship together. The installer just installs SD as another component. Otherwise, Smart Device ships a couple months later. Something like:

You should be able to provide minor updates to the framework, BCL, Windows Forms, VS, independent of each other. We hear "VB refactoring got cut. Maybe next time... XQuery's being dropped because the specs won't ratify in time" Why? Why not just ship an update to VS 5 months later that has VB refactoring in it? Why not ship an update to the BCL that has XQuery classes once the specs finalize?

As the framework accretes more stuff, "next time" becomes a longer and longer timespan.

Maybe we could have had a SQL 2003 that included T-SQL Enhancements, and an XML data type, and maybe SMO. Then later, we could have had a SQL 2005 that added on CLR support.

As Microsoft becomes more transparent, what Microsoft is "thinking about" gets known a lot sooner. With all these interdependencies, I think there's a problem if the gap between "we're thinking about", and doing it, is 3 - 4 years. It gives competitors an opportunity to implement it first, and even possibly control the future direction of the idea.

In the end, I think this will have to change. I just can't see more and more products and components becoming interdependent, where product/component X and Y are deadlocked on each other. I think it's time to cut the ties that bind, and get the dependency house in order.