“Since framework teams at Microsoft can develop managed code software so much faster than they could using C++, their own efforts are dramatically accelerated. They no longer have the time to do coordination with other teams; such coordination would quickly become the bottleneck to getting their own efforts out the door. In a culture such as Microsoft, which values shipped software above all else, such a bottleneck will by necessity be bypassed,” Hollis said.
So Microsoft's productivity is too good? So good that the business process is slowing things down more than coding? Isn't that good? I see this as a problem for managers at Microsoft not necessarily the developers.
I agree there are issues with .NET but this doesn't seem to be one of them. I think the bigger problem will be what to do with enterprise code that was written for 1.1, 2.0, etc and will be around for 10-20 years. Microsoft will need backwards compatibility with all these releases for a long time (1.1, 2.0, 3.0, 3.5, 3.5 SPx).
They're right to worry. It's a headache. Having a new version of the framework every year is also a headache (for desktop development anyway).
I'm not sure what else they can do, though. .NET is their development platform. They've got to keep turning out new stuff. Where else is it going to go?
I've never had any problems with getting installers to install the proper version of Microsoft's .NET framework.
As for getting the right version of .NET on the customer's box their installer works (in VS2008) and InstallShield works with no problems. I've done product installs and enterprise installs with no problems from .NET framework versioning.
I had problems upgrading code from 1.0 to 1.1 and from 1.1 to 2.0 but no problems upgrading to new .NET frameworks since then. I've also had no problems with VS2008 targeting different .NET frameworks. I agree historically it was a problem but M$ has addressed it recently and things seem to work.
If your customers have to download a big new framework before trying out your app, that is one more hurdle you've got to get past in order to sell. Customers who are not computer sophisticated may be scared away and others will consider it too much hassle (frex, if they are on dial-up).
Ya that is a valid point. I've yet to work on a product which targets dial-up or older machines.
The product I work on right now is for engineers who design and manufacture things. 97% of them have .NET 2.0+ with XP or Vista. The remaining 3% are Windows 2k. Almost everyone has .NET 2.0 installed but occasionally there is some squirrelly box in a manufacturing plant with no internet connection. For those customers they just use a CD with the application and framework on it.
If you are targeting customers using Windows 98 or Windows 2k then you are also limited to .NET 1.1 or 2.0.
.NET 3.0 and 3.5+ are XP or Vista only. And as I mentioned before most people in the windows world (at least engineers) are using XP.
It appears that the "central" control is not as centralized as one might think-- in other words, different teams appear to be working (and contributing to the framework) without full knowledge of what other teams are doing, at the risk of dissipating a coherent vision.
True-- but that takes oversight and communication.
Contra the article earlier today, where someone thought he had vanquished The Mythical Man-Month-- the reality is still n(n-1)/2, and there's no silver bullet for that one.
So Microsoft's productivity is too good? So good that the business process is slowing things down more than coding? Isn't that good? I see this as a problem for managers at Microsoft not necessarily the developers.
I agree there are issues with .NET but this doesn't seem to be one of them. I think the bigger problem will be what to do with enterprise code that was written for 1.1, 2.0, etc and will be around for 10-20 years. Microsoft will need backwards compatibility with all these releases for a long time (1.1, 2.0, 3.0, 3.5, 3.5 SPx).