Skip to main content

Why MS Doesn't Do All Their Products in Dot Net

Yag does a great job of explaining to those who don't get it why not all MS products are using DotNet as a native framework.

If you read all the comments, you'll see that part of the issue has to deal with the components that have not yet been put into DotNet (Uniscribe, and features for multi-lingual text etc).

Yag's basic premise though is that no one should expect every single MS app to flip over to DotNet overnight - there's a lot of work involved in moving it over and as the DotNet framework matures, more features get added in.

How this will apply to the entire Avalon scenario is up for grabs. It reminds me a little of how DNA has matured into DotNet and also how FoxPro has matured into Europa. The basic MS approach of development frameworks and almost any new technology (at least in my view) is:

Phase 1: Tell Everyone How they Should Be Doing It (VFP example: VFP 3 / Win Example: COM and Windows DNA)
Result: Some people get it, some people don't.

Phase 2: Show Everyone How To Do It (Ex: VFP 6 with the FFCs / DotNet v 1.0 / COM + )
Result: More light bulbs go off and more people get it

Phase 3: Write Tools so people can do it easier (VFP 8 / Whidbey)
Result: More applications start using it across the board.

Phase 4: Continue to mature the toolset (VFP 9/ _____________ )
Result: More applications use it than don't

Phase 5: Come up with a new idea (or rename the older one) and go back to Phase 1
(just kidding)

Seriously though, that is the basic path that these things take.

But at any step in the road, people get frustrated with waiting for Phase 3 and jump off the wagon. At other times, you may think you're ready for step 3 but you took a wrong course and have to go back to step 2 to get it right.

In some scenarios, MS jumped the gun and did a lot of steps 1 and 2 in secret (umm, research) and then introduced a product like MS Bob only to be assailed by critics and the public.

In the development world, MS has been a little more open in this context, perhaps to avoid the surprises or headaches of newer technology. Some succeed, some fail but each one builds on each other.

Just because MS had a monopoly in DOS didn't mean it would naturally succeed with Windows 9x. Likewise with XP and future versions.

Many of the technologies found in DotNet 1.0 needed to mature to be "production-ready" but just like SpaceShipOne is simply the first version of what will be more tourist trips into space, the conceptual foundation of managed code is the one that MS has built its future on.

Now it's a matter of getting to phase 4 and ensuring you don't lose any more developers on the way.

Microsoft and .NET (by yag)

Comments

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site: http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older. Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments. But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward. FoxPro VFP