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

Merry Christmas

Whether you celebrate now, have already celebrated your past holiday, are planning to, or not, I hope you find yourself surrounded by family and those you love during this holiday season and are able to remember fondly those who are not with you. We often find ourselves buried in work, or too distracted by other problems, to share and remember a few moments with those closest to us. So many of us are separated by huge distances, we often find it easier to focus on those who are out of arm's reach yet so easy to connect with online, instead of those who are right beside us. So do yourself a favour, put down the keyboard (stylus, mouse, etc) and spend that time. I know I will. Merry Christmas. Powered by ScribeFire .

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...

From Writing to AI: the pattern repeats itself

When I was ten years old, my dad bought a computer and, thanks to an advertising supplement in a Superman comic I read, it was a TRS-80. A month later, he dragged the entire family (my mom and brother were not the most enthusiastic) to a class at Radio Shack teaching how to use microcomputers. At the time, I understood why my mom wasn’t that excited: the computer was yet another gadget in the house. But today I find it fascinating. My mother went to Vassar in the 50s. She learned how to type — not a common skill at the time — but it opened doors. Her ability to communicate effectively led her to a career in adult education and later communications work with the CBC (Canadian Broadcasting Corporation). This isn’t a nostalgia post. Today, the ability to use artificial intelligence, be it through Copilot or simply writing the right prompt, is becoming a critical skill. But is it really that novel? In the 1500s and 1600s, the printing press gradually made reading accessible beyond cler...